[API] [Standards] Proposed XMPP Extension: IO DATA

[Fabio Forno]

On Mon, Mar 31, 2008 at 11:57 AM, Pedro Melo <melo at simplicidade.org> wrote:
>
>  I would use type='get' here.
>
>  REST allows you to tunnel the PUT/DELETE verbs over POST in case your
>  transport is "verb-limited" like XMPP (only has get-set mapping to
>  GET-POST on the HTTP side). So I would use the type attribute for the
>  action, overloading the set to do DELETE/PUT when the need arises.

I prefer to have a fully extensible mechanism for verbs. In some sense
ah-hoc commands could be perfect if the vocabulary weren't fixed. Why
not allowing
<command node="foo" action="post"/>, <command node="foo"
action="delete"/>,  or <command node="spam" action="eat"/> if somebody
needs it?

>  Also, not quite sure why you need xmlns='api:rest'. Why not xmlns='/
>  nodename/schemata' ?

I used api:rest for having a different namespace from ad hoc commands,
but the bag should be more or less the same, with just an open
"action". I've separated them because I don't find a way for
generalizing the ad hoc commands while keeping compatibility.

You already have the 'to' attribute on the top
>  level iq stanza to send this to the proper destination.

I want to be able to address different nodes inside the the XMPP
entity. Yesterday I was reviewing the SOAP over XMPP, in order to find
a consistent way for handling this IO-DATA XEP and SOAP and XML-RPC.
Both have the same problem: there is 1-1 relationship between an XMPP
entity and a SOAP or an XML-RPC endpoint, thus forbidding different
logical services inside the same XMPP entity.

bye

-- 
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com