Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-tm-dev] Vote Summary: API changes on RSE?

I'll make the changes to the list* APIs now since they are needed no matter what.  The other APIs still require a look before I make any decisions on them.

David McKnight    
Phone:   905-413-3902 , T/L:  969-3902
Internet: dmcknigh@xxxxxxxxxx
Mail:       D1/140/8200/TOR

Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx>
Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxx

20/10/2006 03:56 PM

Please respond to
Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>

Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
[dsdp-tm-dev] Vote Summary: API changes on RSE?

Dear committers,

from our 8 committers, we've got 7 votes +1,
Michael Scharf did not vote yet.

I think that's sufficient for DaveM to go forward making this change,
and it also encourages us to allow final API fixes until the latest
possible time.
Michael - you'll still have the chance to give a final veto within one
week if you are against this. Please do cast your vote even though we
are going forward already.

Given Lother's comment as a user, I'd suggest trying to get the API
right this time even if it's a little bit more effort - so I'd rather
not do this in a 2-step approach unless the effort is too high.
Mimimizing risk is still more important right now than polishing too
much. So Dave, please use good judgement in how much you want to invest.
Thanks for tackling this.


Martin Oberhuber schrieb:

> Dear committers,
> Dave McKnight has proposed an API change to the IRemoteFileSubSystem
> and IRemoteProcessSubSystem in order to add progress monitors to some
> method calls, such that there is a chance to cancel long running
> operations.
> My personal take is, that although its already very late in the game
> I'd like to accept such API changes because it appears that
> 1. We dont have many clients on openRSE yet. At least none that I'd
> know of.
> 2. Those API changes appear simple and straightforward.
> 3. API changes will become much more difficult than now as soon as we
> have 1.0 released, so better do it now than in the future.
> 4. The API changes will enable our users to write interruptable
> services, i.e. allow something not possible today. So even if our own
> services are not all interruptable yet, it's important to open up the
> API for allowing interruptable services in the future.
> Considering all this, I'm voting +1.
> Committers please cast your votes.
> Thanks
> Martin
> David McKnight schrieb:
>> 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
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member

dsdp-tm-dev mailing list

Back to the top