On Sun, Mar 30, 2008 at 10:59 PM, Johannes Wagener <[EMAIL PROTECTED]> wrote:
> Indeed. If you read the xep you might see that the XEP is very much the > same as you suggest here. Ad-Hoc Commands do also support several > actions: For example execute/next/prev/cancel/complete are actions > supported by Ad-Hoc Commands. We think that this facilitates everything > that is required to completely manage/control a remote process. As I > already mentioned our approach is a very general one. The specs in the > XEP is that open that it is of course possible to do what you suggest, > for example see section 4.2 for getting the schemata. See 4.3 for > sending data. Indeed for M2M I'm concerned about the lack of extensibility of the actions of ad hoc commands, since they their only purpose is describing the which is the next step required for performing an operation, while they don't say anything about which kind of operation we are doing on a node. The type of the the http://xmpp.org/protocol/io-data child tries to fix this limitation with some possible meanings of the command: input/output/get-schemata, but it still uses a fixed vocabulary. Perhaps if you just allow any value for type attribute we reach full flexibility and equivalence with REST. > > > Yes, that's why the XEP uses Ad-Hoc Commands. Because it has already a > session concept as you suggest here. In addition to this it is a widely > supported XEP, we think that - with the very generic io data container > in our specs - it is a friendly way to also support machine2machine > parseable/readable and especially marshal-able services with it. As I > already mentioned our approach is a very general one. The specs in the > XEP is that open that it is of course possible to do what you suggest > here: for example doing it in an asynchronous way there is the sessionid > of Ad-Hoc Commands - especially Examples in section 4.4 and 4.2. I'd let the application decide which is the best way to handle the session. For example there are session associated with a previous authentication process and applied to different nodes, or sessions lasting for ever, even after the restart of the service. The session-id of ad hoc commands is limited from this point of view. However it's not written anywhere that that's the only session-id we can use, and this - I think - keeps the necessary extensibility for session handling. For example the app could get an auth token logging to a given node, and then add the token to the payload of different commands to different nodes. I'd add an example about this to the XEP, just for showing the the concept of session is not limited to the ad-hoc commands scope. Finally I think that the <in/> and <out/> children are unnecessary in commands of type input and output, but that's just a minor adjustment. If you agree with these two observations, I'm absolutely fine with the XEP (I even think that it could be a better way for transporting SOAP itself) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
