[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Mutlithreading in the Team UI
|
OK. Now I see what you mean. I believe you are referring to the cases where
we don't even pop up a progress monitor (i.e. expanding an entry in the
repo view, etc). We are investigating solutions to this.
Mariano Kamp
<mkamp@xxxxxx> To: eclipse team dev <platform-vcm-dev@xxxxxxxxxxx>
Sent by: cc:
platform-vcm-dev-admin@ Subject: Re: [platform-vcm-dev] Mutlithreading in the Team UI
eclipse.org
08/12/2002 01:34 PM
Please respond to
platform-vcm-dev
Hi Michael,
> What do you mean by content provider? Do you mean TargetProvider?
Well, I am talking about a content provider for some view. This is a
problem which is not unique to the team plugin, but I did believe it had
the most impact here.
> As for non-blocking communications, the problem from a CVS, FTP and DAV
> standpoint is that, if an upload or download is non-blocking, a user
could
> modify resources that are involved in the transfer at the wrong time and
> cause corruption either locally or remotely. Some sort of mechanism to
lock
> the resource during the operation would be required.
I do understand that, but I don't believe that it is ok to lock the
whole ui. Not even a repaint is possible.
> So to answer you question: yes, it bothers me when I have to wait for a
> long running operation to finish but I can't think of a safe way to make
> the CVS, FTP or DAV operations non-blocking. I should also say that there
> may be some operations that can be non-blocking and we will investigate
> these.
I believe the platform ui is missing something here. I explained that
below. Could you have another look?
Mariano
>
> Mariano Kamp
> <mkamp@xxxxxx> To: eclipse
team dev <platform-vcm-dev@xxxxxxxxxxx>
> Sent by: cc:
> platform-vcm-dev-admin@ Subject:
[platform-vcm-dev] Mutlithreading in the Team UI
> eclipse.org
>
>
> 08/12/2002 12:23 PM
> Please respond to
> platform-vcm-dev
>
>
>
>
>
> This is a repost. I posted it the first as the 2.0 version was beeing
> finalized, probably this was a bad time.
>
> If this is off no interest or whatsoever I would at least appreciate if
> somebody says so.
>
> Mariano
> ----
> Hi,
>
> I am working on a plugin, where the gui submits long lasting calls (to
> a database). Unfortunately the gui locks up then.
>
> I did see that you guys are facing the same thing when accessing the
> repositories. Especially when you connect to a slow cvs server, e.g.
> sourcforge, the gui is not responsive anymore.
>
> There is another similarity. I would divide the issue into two type of
> calls. a) Operations on cvs, like check-out or update (in my case
> executing queries to a database) and b) calls from a content provider.
>
> I think a) is relatively easy to accomplish in my case (no resource
> modifications needed) -> just spawn a new thread and implement a call
> back, but b) seems to be more complex. The content provider calls don't
> provide a progress monitor and now call backs. I do understand the
> intention, that these calls should be fast, but as even the resources
> can meanwhile live on a ftp or web-dav server this assumptions will not
> even last for the simplest case of resources.
>
>
> I know that platform-ui-dev would be the addressee for most of these
> things, but I wanted to talk to you first, to see how you want to cope
> with it, or doesn't the current behaviour bother you?
>
> I am sure everything could be accomplished with the current API. I've
> also read the article from Chris Grindstaff
> (http://eclipse.org/articles/treeviewer-cg/TreeViewerArticle.htm) where
> he proposes to show some "loading" image and using a callback to deliver
> the real information, but he wasn't going into any detail, how to do
> that in a non-ugly fashion. I am just wondering if in 3.0 there will
> evolve something elegant to solve this common problem?
>
> On a side bar (just to be on-topic ;-). I really like the 2.0 Team
> API. I like the full exposure of the cvs functionality and still the
> tight integration into the platform. Great job.
>
> Cheers,
> Mariano
>
>
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>
>
>
>
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
