RE: [dsdp-tm-dev] Vote Summary: API changes on RSE?

["Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>]

Oh I wasn't sure if I count as committer....

+1

Michael 

> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Martin Oberhuber
> Sent: 20 October 2006 21:56
> To: Target Management developer discussions
> Subject: [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.
> 
> Cheers
> Martin
> 
> 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
> http://www.eclipse.org/dsdp/tm
> 
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>