[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-tm-dev] Re: (dsdp-tm-dev) API change for IRemoteFileSubSystem
|
Dave,
Regarding the order of arguments, I think having IProgressMonitor as the
last argument is consistent with the rest of Eclipse (the methods in
IResource for example). As to whether we should maky any API changes at
this point, I think it's very late in the game to be making such changes.
However, being able to cancel a query is a pretty fundamental thing. What
if the query is taking a long time? Without this change, users would not be
able to cancel any query to the host, which in my opinion is a fairly
serious restriction.
So my vote is a yes, but we should keep the changes to the absolute minimum
possible.
Cheers,
Kushal Munir
Websphere Development Studio Client for iSeries
IBM Toronto Lab, 8200 Warden Ave., Markham, ON
Phone: (905) 413-3118 Tie-Line: 969-3118
Email: kmunir@xxxxxxxxxx
David
McKnight/Toronto/
IBM@IBMCA To
Sent by: Martin Oberhuber
dsdp-tm-dev-bounc <martin.oberhuber@xxxxxxxxxxxxx>
es@xxxxxxxxxxx cc
Target Management developer
discussions
10/19/2006 05:03 <dsdp-tm-dev@xxxxxxxxxxx>
PM Subject
[dsdp-tm-dev] Re: (dsdp-tm-dev) API
change for IRemoteFileSubSystem
Please respond to
Target Management
developer
discussions
<dsdp-tm-dev@ecli
pse.org>
1) I did consider putting this to a vote but then thought it was too
trivial a change for that. It was really something that should have been
done from the start but it was an oversight. At this point I haven't
committed anything since I wanted to see the reaction to my email and I
guess that was a good thing.
2) I was wondering about the order of arguments too - I suppose the last
argument is consistent with RSE, although, I'm not sure how consistent it
is with other things. I guess the natural thing would be to place it at
the end. I would like to make the corresponding changes to the list*()
APIs for IRemoteProcessSubSystem as well. I'm still not sure whether we
should have monitors for all the methods right now without taking a closer
look at their usages. I'm wondering if maybe we ought to phase this in
two parts: first to deal with queries (the most obvious case) and second
phase to deal with the other subsystem calls. Any thoughts on that?
Before getting into the details, I suppose we may as well have a vote on
whether or not we should make any API changes at this point.
____________________________________
David McKnight
Phone: 905-413-3902 , T/L: 969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail: D1/140/8200/TOR
____________________________________
Martin Oberhuber
<martin.oberhuber@windriv
er.com>
To
Target Management developer discussions
19/10/2006 03:38 PM <dsdp-tm-dev@xxxxxxxxxxx>, David
McKnight/Toronto/IBM@IBMCA
cc
Subject
Re: (dsdp-tm-dev) API change for
IRemoteFileSubSystem
Hi Dave,
Hang on a second.
1. It's really REALLY late for such an API change. Simply considering an
API change that late makes only sense because we are approaching a 1.0
release and we don't seem to have too many clients yet. In the future,
this will not be possible any more. And even now, we should at least
vote among all committers if we are all OK with such a change that late
in the game.
2. If we make such an API change we should do it right:
2.1. All other methods in IRemoteFileSubsystem which take an
IProgressMonitor, use the monitor as the LAST argument. For consistency,
the list* methods should also use it as the LAST argument and not the
first.
2.2. Methods create* also dont have an IProgressMonitor. I guess they
should also get one.
2.3. Method move() exists with and without the monitor. I guess the one
without the monitor should be removed.
2.4. Method delete() is deprecated without the monitor. I guess it
should be removed.
2.5. rename(), setLastModified(), setReadOnly() should also get a monitor.
2.6. I'm not sure about methods getParent* and getRemoteFileObject* --
are they resolved without target interaction or should they also get a
monitor?
So, Dave -- given my concerns above: can you come up with a proposal
which of these make sense or not, and send a proposal to the mailing
list such that we can vote on it?
Thanks
martin
David McKnight schrieb:
>
> I'm going to be changing all the IRemoteFileSubSystem.list*() APIs to
> take an IProgressMonitor as the first argument. While looking at bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=160777 I noticed that we
> aren't passing a monitor into the IFileService layer and therefore the
> RSE framework is not supporting the cancellation of queries. In order
> to fix that, I need to change the listFiles() and other list APIs to
> take a monitor. There may be extensions that use these APIs so this
> is a headsup that it will be changing (rectifying it is simple though).
> ____________________________________
> David McKnight
> Phone: 905-413-3902 , T/L: 969-3902
> Internet: dmcknigh@xxxxxxxxxx
> Mail: D1/140/8200/TOR
> ____________________________________
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dsdp-tm-dev mailing list
>dsdp-tm-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
>
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
