[Standards] Feedback on I/O Object Forms

Chris Mullins chris.mullins at coversant.net
Fri Mar 16 01:02:25 UTC 2007


[Overall Impressions]

 

According to the author, they are trying to:

-          Discover Support Using Disco

-          Retrieve a list of support Ad-Hoc Commands along with enough
metadata to call those commands (via XSD, in a way similar to WSDL)

-          Call the Commands in either a synchronous or async way. 

 

Essentially (this is me talking, interpreting what I think the XEP
author said), they're looking to replace SOAP Based Web Services with
XMPP Based services. They're looking to do this due to the nature of
their very long running transactions and the ability of an XMPP Service
to send an "all done" message, and for the client to get it at some
point in the future. The Async Nature of XMPP is really the main reason
for things.

 

(Overall, I quite like the goals here. I think building rich Services
atop XMPP will be important to the long term success of the protocol, as
well as the continued divergence from "just an IM protocol".)

 

Upon first read of the XEP, I didn't understand this - so clarity was
(for me) missing. 

 

So, the overaly purpose of the XEP is to build a framework for a SOA
style Service. I'm not quite sure how this differs from XML-RPC over
XMPP, or even SOAP over XMPP, but that's the case. I think it's primary
difference is the desire for an async result due to a long running
process. 

 

[Object Spaces]

The XEP author is defining a custom namespace, called Object Spaces, in
which parameters can be passed to & from the Service. These are defined
to look like:

<x xmlns='http://xmpp.org/protocol/io-object-form' type='submit'>

        <in>

                <proteinname>CAB08284</proteinname>

        </in>

</x>

 

I don't understand how this differs from an X-Data Form. The author
keeps saying that X-Data won't do the trick, but either I'm missing
something or the author is missing something. I don't understand why,
during discover, the service wouldn't send back a data form (this is the
required argument list):

<x xmlns='jabber:x:data' type='form'>
      <title>Method Arguments</title>
      <field type='hidden' var='FORM_TYPE'>
        <value>Object Spaces</value>
      </field>
      <field type='text-multi' var='proteinname'><required/></field>
</x>
    
.. and the client would then fill this form out as a submit form:
<x xmlns='jabber:x:data' type=submit>
      <field type='hidden' var='FORM_TYPE'>
        <value>Object Spaces</value>
      </field>
      <field type='text-multi'
var='proteinname'><value>0</value></field>
</x>
 

The resulting message would also have an X-Data from sent from the
server back to the client with the results.

 

I can see defining some new field types:

-          Base64 Binary Data 

-          XML Data

 

I understand the argument, "This is machine to machine communication,
and X-Data is meant for human-to-machine communication", but I think
it's flawed. X-Data (to me) seems to allow machine-to-machine with no
trouble. 

 

[Async Results]

I'm not sure the proposed mechanism for Async Results will work the way
they're intended. Sending a Message to a bare JID to indicate, "I'm
done" is (in my experience) somewhat bug prone. It's possible 2
resources for that JID are online, and there's no guarantee the right
resource will get the result. The Offline delivery mechanism is nice and
almost gets us what we want, but it's still not quite right. 

 

I'm tempted to go a slightly different route (I've never tried it, but
it seems more elegant):

1 - Create a GUID JID for each problem that's submitted and for which an
async result is expected. 

2 - Have your Bare JID subscribe to the presence of the new JID. 

3 - When the Problem is complete, have the problem announce "available"
presence. 

4 - At some point in the future, delete the JID. 

 

This has a few advantages: 

1 - All Resources waiting on the result get notified. 

 

2 - When my client comes online, I can check using IQ:Last to see if the
problem has been completed while I was away. This is done in a stateless
way, so if another client comes online and checks, they also see things
are completed. If Offline Messages are used, only the first client to
check sees the result. 

 

3 - You can provide status updates via Presence Priorities. You can
continually announce "unavailable", but include whatever status update
you want. This would allow a GUI to be put somewhere showing progress. 

 

 

--

Chris Mullins

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070315/f9a8f7f5/attachment.html>


More information about the Standards mailing list