Re: RPCTF: Should RPC be core or an extension ?

Hi guys:

Just to pop in here for a moment, I agree wholeheartedly that RPC (and in
fact request-response in general) seems much cleaner as a normative
extension to the core protocol.  I just wanted to note that I currently do
rather like using the actual "extension" term for things like message
exchange patterns and RPC conventions.

This slots in with recent thinking about the more abstract "infoset" view of
SOAP - whether or not this stuff is serialized on the wire, if we give it
clear names we can talk about it and refer to it in both text and code.

(and if we imagine an SMTP binding which supports multiple message patterns,
for instance, we may very well have an actual header block which indicates
"this is an RPC message")

--Glen

----- Original Message -----
From: "Jacek Kopecky" <jacek@idoox.com>
To: "John Ibbotson" <john_ibbotson@uk.ibm.com>
Cc: <xml-dist-app@w3.org>
Sent: Wednesday, July 25, 2001 1:00 PM
Subject: Re: RPCTF: Should RPC be core or an extension ?


> +1 with Marc's change. I wasn't against visibly removing RPC from
> the core of SOAP, I just didn't like the term "extension" used
> here. 8-)
>
>                             Jacek Kopecky
>
>                             Idoox
>                             http://www.idoox.com/
>
>
>
>
> On Wed, 25 Jul 2001, Marc Hadley wrote:
>
>  > +1 for John's proposal. I think I'd prefer to replace "architected
>  > extension" with "a set of rules/conventions" to prevent confusion with
>  > SOAP header extensions which I don't think really play a part in the
RPC
>  > conventions and encoding rules.
>  >
>  > Marc.
>  >
>  > John Ibbotson wrote:
>  > >
>  > > Should RPC be part of the core SOAP specification or an architected
>  > > extension ?
>  > >
>  > > I believe the SOAP 1.1 specification confused matters by including
sections
>  > > on RPC and encoding. Readers of the specification came to the
incorrect
>  > > conclusion that SOAP was inextricably linked to RPC. As Henrik
pointed out
>  > > inthe early days of the WG, SOAP is really only a single way message
with
>  > > RPC being a convention for linking two single way messages into a
>  > > request/response pair together with an encoding mechanism. By
removing  RPC
>  > > from the core specification and placing it into a separate extension,
we
>  > > have the opportunity to correct the confusion that I believe
originates
>  > > from SOAP 1.1.
>  > >
>  > > There is a second reason for removing RPC from the core
specification.
>  > > There is a large body of users (the EDI community via ebXML) for whom
RPC
>  > > is not the preferred invocation mechanism. They operate with a
document
>  > > exchange model which may include boxcarring of business documents in
a
>  > > single message each of which is of equal processing importance. If
the WG
>  > > perpetuates the perceived importance of RPC by including it in the
core
>  > > specification rather than viewing it as an extension, then acceptance
of
>  > > SOAP in some communities may be diminished.
>  > >
>  > > Comments please,
>  > > John
>  > >
>  > > XML Technology and Messaging,
>  > > IBM UK Ltd, Hursley Park,
>  > > Winchester, SO21 2JN
>  > >
>  > > Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
>  > > Fax: +44 (0)1962 816898
>  > > Notes Id: John Ibbotson/UK/IBM
>  > > email: john_ibbotson@uk.ibm.com
>  >
>  > --
>  > Marc Hadley <marc.hadley@sun.com>
>  > Tel: +44 1252 423740
>  > Int: x23740
>  >
>

Received on Sunday, 29 July 2001 00:41:59 UTC