[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia] [wsrp-wsia joint interfaces] Re: April 9 (Embedded) conf call.
Alan, Rich, thanks for the productive conf call and the work done so far on Embedded. Couple of thoughts on today's conversation... 7.1 Lifeycle. We discussed the consumer choosing whether he wanted to engage in a stateful/stateless lifecycle. Not sure the consumer has a choice does he? If the producer defines stateful operations (ie, they take as an arg a session handle) then the consumer is going to have to comply in order to make that call. Or the producer might define additional stateless operations where a bunch more data needs to be supplied on every request? The former (stateful, with a session handle) would be more efficient (less data travelling on the wire), and the latter might allow simpler implementations on the consumer side? So if a producer chose to supply both porttypes (meaning published interface containing certain operations) then that's his prerogative and very nice of him to do so, but if he only published a stateful interface the consumer would just have to work with that? 7.6.4 Rich pointed out that it's not event-based, not notifying multiple subscribed consumers - might be worth clarifying that. In which case I'm then not sure why a producer must notify its consumer what properties have changed, since won't it have been the consumer that initiated the change? So (considering performance here too) do we just want to say that a producer MUST notify its consumer that a property change was/was not successful (rather than returning a full list of the new current property settings)? Also do we want to state that producers MAY support the ability to change multiple properties at once? thanks, :-) gr 603.559.1556
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC