[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative API
Mike, Great, this is write up is much cleaner than the previous one. * entity reference. <AA-1> What is the use case for this? Do we really need it? * API <AA-2> Is there any reason why the updateConsumer and deregisterConsumer functions have the ConsumerRef as a separate parameter when it's already part of the ConsumerCtx? <AA-3> It would be nice if we can complete the propose API. At least for me, it will be much easier to visualize the complete lifecycle. * Data <AA-4> What is the use case of a consumer sending session data to the producer (as part of the PreambleData) ? <AA-5> The FragmentRequestData does not contain something like window state <AA-6> FragmentResponse defines responseProperties, are those properties to be updated in the consumer or headers to be send back to the client ? * Session creation <AA-7> How are you proposing session creation will happen for the different scopes? Thanks and regards. Alejandro Michael Freedman wrote: >The following is an updated version (attached) of the counter-proposal >to draft 0.1.2 I sent last week. The main changes are the session as >well as the entity references are created/sent by the consumer. There >is also a new reference for an entity session -- the session >conversation with a specific entity. Finally, I have simplified the >method signature defining a single ConsumerCtx parameter to hold all the >(potential) references. There are still alot of details to put in here >so we have a consistent understanding but I though you would like an >early view. While waiting for these details the key to looking at this >is to think in terms of the consumer vs. the producer. This API doesn't >represent (many) abstractions as concrete objects in the producer. >Rather, most abstractions are seen as elements/scopes defined by the >consumer that are passed by reference to the producer. The Producer is >thus freed to represent themselves internally anyway they want to -- >merely needing to build a mechanism that maps from these references to >their implementation. > -Mike- > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC