OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative API


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?


<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.


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