Re: [soapbuilders] Re: alternative transports
- On Fri, 02 Nov 2001 11:00:25 -0000, in soap you wrote:
>--- In soapbuilders@y..., Simon Fell <soap@z...> wrote:I've been working from your proposal in rpc-jig. Looking through
>> Thanks for the pointers, reading over them now. I would see
>> one way async & multi-hop scenario's to be critical long term.
>Yes indeed, it looks that way is going to be quite interesting. Until
>now, the SOAP-over-Jabber experiments have seemed pretty much to be
>request/response style. If you (or anyone else on this list! :-) have
>any thoughts or wishes etc - especially those that have already used
>one-way async and multi-hop messages - please don't hesitate to let
>the rpc-jig  list know, as all input and experience is welcome.
>[That said, I think using a simple :x: based attachment to a Jabber
><message/> element is probably the right way to go for these types,
>being the most generic and therefore the most flexible...]
>DJ (sporadic 'net connection at the moment)
the jabber docs, it appears that <iq> implies a request/response
exchange [even though its over an async transport], is that correct ?
if so using <message> might be better, but that would probably need an
additional value for the type attribute defining.
> I've been working from your proposal in rpc-jig. Looking throughcorrect ?
> the jabber docs, it appears that <iq> implies a request/response
> exchange [even though its over an async transport], is that
> if so using <message> might be better, but that would probably needan
> additional value for the type attribute defining.Hi Simon
You're right, and indeed later in the thread you pointed to on the
RPC-JIG mailing list, I (and others) seemed to agree that the
<message/> element could be used as well . That is to say, the IQ
model is appropriate for request/response usages of SOAP, and the
message model is appropriate for the async, one-way and multi-hop
usages. There's no reason why we need to restrict ourselves to just
one Jabber element. I think I drew a parallel somewhere in that
thread to the split-personality of many of the standard jabber:
namespaces, e.g. jabber:x:oob and jabber:iq:oob.
May I humbly suggest we continue this on the RPC-JIG list, so as not
to lose focus or messages?
Thanks, and thanks for your input