Re: [dsdp-tm-dev] Committers please vote: API changes on RSE?

[javier.montalvoorus@xxxxxxxxxxx]

+1

Javier Montalvo Orús
Engineering
Tools 
Symbian Software Limited.

Tel: +44 (0)207 154 1091

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

20/10/2006 01:15

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

To	Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
cc
Subject	[dsdp-tm-dev] Committers please vote: API changes on RSE?

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

Do more with Symbian. Make sure you visit the Symbian
Smartphone Show, 17-18 October 2006, Excel, London

http://www.symbiansmartphoneshow.com

---

   ****
******************************************************************
Symbian Software Ltd is a company registered in England and Wales
with registered number 4190020 and registered office at 2-6
Boundary Row, Southwark, London,  SE1 8HP, UK. This message is
intended only for use by the named addressee and may contain
privileged and/or confidential information. If you are not the
named addressee you should not disseminate, copy or take any action
in reliance on it. If you have received this message in error
please notify postmaster@xxxxxxxxxxx and delete the message and any
attachments accompanying it immediately. Neither Symbian nor any of
its Affiliates accepts liability for any corruption, interception,
amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in
compliance with Symbian corporate policy. *************************
*********************************************