[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Mutlithreading in the Team UI
|
Mariano,
What do you mean by content provider? Do you mean TargetProvider?
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.
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.
Michael
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
