|
Email lists >
XMPP Extension Discussion List >
Re: [Standards] Proposed XMPP Extension: IO DATA >
Re: [Standards] Proposed XMPP Extension: IO DATA
Re: [Standards] Proposed XMPP Extension: IO DATA
This post if a part of this thread
|
2008-03-30 12:09:49 |
|
|
Re: Proposed XMPP Extension: IO DATA
|
On Sun, Mar 30, 2008 at 2:16 AM, Johannes Wagener
<johannes.wagener 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 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 jabber.bluendo.com
|
|
|
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|