Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tm-dev] Re: (dsdp-tm-dev) API change for IRemoteFileSubSystem

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

Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>, David McKnight/Toronto/IBM@IBMCA
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

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

Back to the top