Skip to main content

[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


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


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

             IBM@IBMCA                                                  To 
             Sent by:                  Martin Oberhuber                    
             dsdp-tm-dev-bounc         <martin.oberhuber@xxxxxxxxxxxxx>    
             es@xxxxxxxxxxx                                             cc 
                                       Target Management developer         
             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                                             

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                                         >                                                                   
                                   Target Management developer discussions 
 19/10/2006 03:38 PM               <dsdp-tm-dev@xxxxxxxxxxx>, David        
                                   Re: (dsdp-tm-dev) API change for        

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
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

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?


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
> 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

Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member

dsdp-tm-dev mailing list

Back to the top