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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: RE: [wsrm] Draft Agenda for Tuesday April 8 WSRM TC meeting Teleconference]


Hi Dock,

I would argue with your opinion. As the most common web services use cases are based on the request/response message pattern, it would be very unfortunate not to provide a solution for it. If we define only the asynchronous one-way message reliability, we may lose the chance of the wider acceptance/deployment of the specification.
I agree with Iwasa on the removal of that sentence from the charter.

br,
Magdolna

-----Original Message-----
From: ext Dock Allen [mailto:dock@mitre.org]
Sent: April 08,2003 16:36
To: iwasa
Cc: wsrm-TC
Subject: Re: [wsrm] Draft Agenda for Tuesday April 8 WSRM TC meeting
Teleconference]


Aren't there issues for RPC that do not apply for messaging.  Either
there is an intent is to be able to build RPC on top of this, or not.
We should be clear going in.  I recommend not defining this as an
objective, unless we're ready to undertake the work of verifying that it
can be done in a useful way.

Dock

iwasa wrote:

> All,
>
> I would like to raise one discussion item for charter.
> Currently, out of scope items include "Synchronous RPC
> at the application level", but it would require a clarification.
>
> This was originally included here to simplify the spec,
> since including both RM and RPC sometimes
> make the spec confusing.
>
> However it was not intended to prohibit to use the spec
> for synchronous RPC at application level. So it means
> we could include how to use the spec for RPC. And the
> spec shouldn't prohibit to do so.
>
> Thus, I would like to propose making a clarification
> for the sentence with one of the following options:
>
> 1.Adding a clarification like:
> Synchronous RPC at the application level.
> *Note this is included here to simplify the spec,
>   since including both RM and RPC sometimes
>   make the spec confusing. This doesn't mean the spec
>   should not be used for synchronous RPC at application
>   level, but the spec must allow to do so. In addition to this,
>   the spec may have normative description how the
>   spec is used for "Synchronous RPC at the application
>   level", if appropriate.
>
> 2. Removing the sentence to avoid miss-understanding.
>
> And I would propose #2 option above.
> Thanks,
>
> Iwasa




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