On Mon, Sep 7, 2009 at 12:12 AM, Egon Willighagen <
egon.willigha...@gmail.com> wrote:
> Dear Wasaq,
>
> On Sun, Sep 6, 2009 at 8:28 PM, Waqas Hussain<waqa...@gmail.com> wrote:
> > 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).
>
> Can you elaborate on this? If you run a service discovery on
> ws1.bmc.uu.se you will see various JIDs, each with one and often more
> functions...
I mean the basic concept of namespaces (the concept of a class is similar,
if you only consider static members). Basically, instead of GlobalFunc1,
GlobalFunc2, and so on, SomeNamespace.Func1, SomeNamespace.Func2, and
possibly SomeOtherNamespace.Func1 (same function name, possibly with a
different meaning). I'm using the '.' operator here, but others ('::', '->',
'/', etc) are used in other languages and contexts to show membership.
Why this is useful should be obvious. The reason is the same as the reason
behind XML namespaces, and Java packages, and C++ namespaces. Even VB6 has
modules. Your example of various components running under a host implies
that you are only thinking of servers exposing services, and using
components to group them. But why really shouldn't a component, or even a
single client resource expose multiple services? The protocol might as well
be generic.
Note that pretty much any modern ORB system has support for these. Even
CORBA exposes an object hierarchy, not a single object per-host. See
http://en.wikipedia.org/wiki/Object_request_broker - I'm personally familiar
with .NET Remoting, WCF, DCOM, RMI, and various RPC mechanisms (SOAP, REST,
etc), etc. Exposing hierarchies of objects, and not just a single object
per-host looks like a pretty standard feature.
Note that if you simply don't want to support that in IO Data, then please
clarify the reasons, because that's a pretty useful feature.
> 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.
>
> I do not understand how you see the number of needed IQ requests to
> make generation of marshalling code at runtime difficult. Could you
> please explain?
Think of a dynamically generated UI. A UI generated from the collection of
schemata exposed by an IO Data service. All that is being generated on the
fly. Now assume the service has a hundred functions. Do you suppose the 200+
IQ requests required to generate said UI might slow things down a bit?
Unless of course IO Data clients are supposed to be statically generated. If
that is the case, then it needs to be explicitly stated.
> 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 as I know there is no standard for versioning on XML schemata,
> other than with the schema itself. Indeed, the current proposal does
> not propose a mechanism for doing this,
> and defines the schemata itself is 'contract' for the service interaction.
>
That is true, but various parts of XMPP do have support for versioning.
Roster versioning and entity caps in presence being examples. In my opinion,
something which requires multiple IQ requests to refresh is more in need of
versioning that either of those.
I do understand that if you wish the change that contract regularly
> *and *you wish the services to keep the same JID, that this places
> stress on the clients. However, I am not sure that the XEP should
> provide best practices for dealing with service providers with such
> wishes.
>
So.. basically once you have defined a contract, it shouldn't ever change?
API versioning is a pretty basic and quite useful concept. All APIs get
updated. Some more frequently than others. Pick up any modern API, and you
do see some versioning support.
If IO Data is to be limited to static services, which never change, that
should really be explicitly stated. Otherwise it needs a better versioning
system than re-querying a hundred nodes.
If we could get to, or reuse, a different XEP for specifying detailed
> versioning information for schemata, this would have been useful
> indeed. But in the lack thereof, I think that using the XML Schemata
> itself as exact versioning is a wise choice, even though it for larger
> schemata this puts some stress on the bandwidth.
>
The problem with that of course is, simply checking for schemata change
costs a hundred IQ requests (two hundred if you re-disco, which you would if
you need to support addeding/removing functions).
That said, using the current XEP, you could simply consider using
> <xs:include/>'s which gives you exact control over the schemata
> versions your services are using. I think this provides the clients
> exact caching control on included schemata.
>
And use what? HTTP? Something which causes an external request should be
explicitly defined in the XEP. And if you indeed do mean an HTTP request,
then that has it's own set of problems, which need to be in the Security
Considerations section of the XEP.
Looking forward to hearing from you about the things that were not
> clear to me in your comments,
>
> Egon
>
> --
> Post-doc @ Uppsala University
> Blog: http://chem-bla-ics.blogspot.com/
>
Aside from what I pointed out, I'm quite satisfied with the XEP, and intend
to make use of it. I'm not particularly against the current IO Data schemata
protocol. It's just that in its current form it doesn't scale and has no
support for a dynamic system. If it isn't supposed to scale or be used in a
dynamic system, then that should be clearly specified.
Lastly, do you agree with my opinion that Asynchronous Ad-Hoc commands
deserve a separate XEP?
--
Waqas Hussain
