[dsdp-tm-dev] Re: (dsdp-tm-dev) API change for IRemoteFileSubSystem

[David McKnight <dmcknigh@xxxxxxxxxx>]

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

19/10/2006 03:38 PM

To	Target Management developer discussions <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