On Wed, Sep 9, 2009 at 10:58 PM, Peter Saint-Andre <stpe...@stpeter.im>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/6/09 12:28 PM, Waqas Hussain wrote:
>
> > Now with the short answers out of the way, I do have some concerns.
> >
> > The specification does three things: One, it defines a way to do ad-hoc
> > commands asynchronously (possibly across user sessions). Two, it defines
> > a new payload format for ad-hoc commands. Three, it defines a schema
> > discovery format. I think at least the asynchronous ad-hoc command part
> > deserves to be separate from the other two.
> >
> > What I would prefer:
> >
> > 1. An Asynchronous Ad-Hoc Commands XEP.
>
> I agree that it makes sense to split the asynchronicity stuff out of
> XEP-0244 into a separate spec -- perhaps a new XEP but I think
> preferably a revised version of XEP-0050 so that everything about the
> core of ad-hoc commands is in one specification.
A revised XEP-0050 sounds fine.
> 2. The IO Data custom payload/schema format in an IO Data XEP, but as
> > payload for ad-hoc commands, not just asynchronous ad-hoc commands.
>
> IMHO this can remain in XEP-0244.
Agreed.
> > 3. Other formats in the future (SOAP, whatever). I would love a WSDL
> > discovery XEP.
>
> Wouldn't those be separate specs?
Yes, I did mean separate specs. I should have been clearer.
> Some problems with the XEP:
> >
> > 1. The XEP basically allows a service to expose a set of global
> > functions. There is no possibility for function namespaces. This is
> > similar to the SOAP over XMPP XEP, where you can have only one service
> > end point per-JID (which I consider a non-minor deficiency).
>
> It's not yet clear to me (from this message or your reply to Egon) what
> changes you want to make. Could you perhaps suggest some text?
On further consideration I can see that the node values can consist of any
UTF-8 characters. So I can have nodes 'physics/calculate_distance' and
'chemistry/balance_equation' on the same JID (the point being the hierarchy
denoted by the '/'). I'm not sure if a guideline about this in the XEP for
IO Data consumers, and possibly a preferred hierarchy indicator ('/' or '.')
would be useful. This is just a convention though, to help in mapping
existing APIs directly to IO Data.
> 2. The schemata discovery protocol requires at least two IQ requests per
> > exposed function. For a service exposing a large number of functions,
> > this makes it impractical to use for generating marshalling code at
> > runtime. And there’s no allowance for caching the schemas (i.e., you
> > have to load all of them every time, since there is no assurance that it
> > didn’t change since you last checked). For something like Prosody, where
> > we might be exposing hundreds of functions, which can appear and
> > disappear when modules (including third-party modules) are
> > loaded/unloaded, this makes for some nastiness.
>
> As far I understand your concern, this is more a matter of versioning
> the payload namespaces than exactly a problem for XEP-0244, but perhaps
> I'm missing something.
>
My first concern here is scalability. The schemata protocol does not scale
well. As an analogy, think of the roster. Think what it would be like if the
roster protocol required that after retrieving the roster, you must send
separate IQs to discover meta-data (subscription, nick, etc) and disco#info
data for each individual roster item (2 IQ requests per roster item). How
well would that scale for large rosters (without roster versioning and caps
hashes)?
Continuing with the roster analogy, Egon Willighagen basically says that the
roster and the item meta-data and disco#info data should all be static for a
given service. Now, this doesn't make any sense for dynamic web services.
But let's assume the XEP doesn't cater to those. But even static web
services need to evolve. Any professional web service with a static contract
that you are likely to find is versioned (e.g., see Google's various AJAX
APIs).
And no, this isn't a problem of versioning of payload namespaces. The
payload is not the API. It is data on which the API works. Continuing with
the roster analogy, the payload namespace version is like caps has of the
disco#info data of a single roster item. But I'm referring to versioning the
roster itself. (Since the disco#info and item meta-data is local to the IO
Data service, the roster's version could simply encompass changes in all of
these, eliminating full roster retrieval, and two IQs per roster item to
refresh item data).
Now, I'm not stuck on this. The schemata protocol still serves its intended
purpose of API discovery. It's just that the lack of scalability, and the
(in my opinion, unreasonable) requirement of a never changing API contract
limits its usefulness.
Thanks for your feedback.
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
--
Waqas Hussain
