[Standards] Proposed XMPP Extension: IO DATA

Fabio Forno fabio.forno at gmail.com
Sun Mar 30 17:09:49 UTC 2008


On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener
<johannes.wagener at med.uni-muenchen.de> wrote:
> Proposed XMPP Extension: IO DATA
>
>
>  Abstract: This specification defines an XMPP protocol extension for
>  handling the input to and output from a remote entity.
>

Some remarks.
You write "While SOAP over XMPP supports complex functionality it
lacks an obvious mechanism for asynchronous usage (for example it has
no default RESTful design: there is no sessionid like in Ad-Hoc
Commands)."
While it's true that in SOAP+XMPP specs there is no asynchronous
message exchange pattern (and that was a mistake, though I think it's
possible to add a new MEP), this is not related to REST. Neither the
concept of session id is somewhat related to REST, at the contrary,
REST explicitly forbids things like session ids. The basic principles
of REST in fact are:
- being able to address "resources" with URIs;  since ad hoc commands
end points nodes, whose URI may be
xmpp:entity at example.org/resource;node=nodename (if I remember well),
they are RESTful in this aspect
- be able to do actions (verbs like post/get/delete/put) on that
resources; in this ad hoc commands are not RESTful, since they don't
define a real action, they just provide a generic "execute"
- stateless operations, and state or sessions are intentionally left
out from REST, since they are too much application dependent; ad hoc
commands have just a limited "session" concept, which is a sequence of
operations forming a wizard with a start and an end. However
applications may have different concepts of sessions, such as all
operation between a login and logout, on a given resource or on a set
of resources, or all operations in period of time; these are all
concepts more complex than the model provided by ad hoc commands. For
this reason I'd leave the responsibility of handling a session to the
application, which should find a way for passing state information
among requests as cookies or other mechanisms in HTTP.

bye

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



More information about the Standards mailing list