[standards-jig] comments on JEP-0060
JHildebrand at jabber.com
Sat Jan 18 01:24:33 UTC 2003
/me gets caught up in the burgeoning flame war.
sorry in advance...
> > Like JoeH said, if we establish a standard for naming var's in
> > these xdata forms, then it's completely machine readable.
> So at least you admit there is no such standard. (1)
JEP-0053 is at least a beginning. Please comment on your perceptions of its
inadequacies in a separate thread, but suggesting that there is *no*
standard is a little... disingenuous.
> >In addition, do you
> >forsee components or other automated process which set specific
> >configuration options for a node, or do they just request instant
> >nodes, etc... Please present me with some use-cases and I'll
> be happy
> >to take them as input into the design process of this
> protocol (which
> >everyone wants).
> In my opinion how this is done is a choice that should be
> made entirely
> by whoever builds a pubsub component. I don't care if it's webbased,
> classic jabber messenger based, if it comes from a groupchat room, if
> it uses some kind of XML or an x:data form or tiny litte nano
> A truly generic spec. will allow all of those.
That last bit doesn't make any sense to me. How does having no defined
standard for configuration make the configuration more computer-readable?
> >There is no requirment that says that
> >your pubsub impl MUST "communicate" with humans.
> As long as there is no standard or specifaction(see 1)(see 2) I'm
> communicating either with humans when I use x:data forms or one f*ing
> clever AI.
Or a programmer who has looked at the form that an implementation uses, and
applies a little bit of string-matching logic, and holds a club over the
head of the server implementor not to change the interface. Or there's a
document that the implementor uses as a contract with the users of that
service. I've written lots of programs that know how to fill out HTML forms
on the web. I didn't have to write an AI to do it. I just needed to know
what fields that particular form was expecting.
> >The requirement is
> >that a node be configurable (discussed above), and that
> >must use the x-data protocol so that it can be presented to humans
> >when desirable to do so.
> Wich is exactly what x:data was once meant for. Wich is great, and it
> works great. If I want to communicate with humans. If I don't want to
> communicate with humans (or in a way that does not involve x:data, eg
> for client that don't support it) I have no need for x:data do I?
No, but you need a generic protocol for specifying which name/value pairs
you need filled out. You might want some type information for redundancy
I bet by the time you are done defining that protocol, it will look
suspiciously like x:data.
Now, sometimes users *will* want to be able to configure a node manually.
In that case, you'll have to create a way of prompting a user for the data
> *sighs* I guess I have to keep saying this over and over. I'm NOT
> opposed to using x:data with PubSub. In fact, it's brilliant! For
> *some* uses of PubSub. I've never said anywhere that humans
> don't need
> pubsub. I've never said you can't write a JEP on using x:data with
> PubSub. In fact I've even suggested it! Where are you getting
> all this
> from? I hope it doesn't have to do with your own remark above.
No, but you are saying that you don't think *this* jep should include
x:data. I thought that PGM's offer to include this language should have
been good enough:
* Any node configuration available MUST be done using the x-data protocol.
What this means is that in some cases of pubsub, a node MAY not have any
configuration. In those cases, the server MUST respond to the iq-get for the
config form with an error-501: Not Implemented.
but I didn't see any comment from you on that. What about changing MUST to
SHOULD? Would that be acceptable to you? Then you could configure the
nodes with whatever protocol you want, but people that want to interoperate
can still do so.
> Ok, at least admit:
> That (considering the current state of x:data amongst other things),
> making x:data the mandatory means of configurating nodes make the JEP
> as it currently is too horribly flawed to be called generic PubSub.
What "current state"? It is a Final JEP. It works. It's been implemented
in lots of places. Other JEPs already depend on it (MUC). Implementations
of MUC exist, and it works fine for that as well. I've even written code
that knows how to process x:data forms without human intervention in order
to create/configure MUC rooms, so I know it is possible.
I take offense at "horribly flawed" without any suggestions for improvement.
I'll assume that you meant something a little less inflamatory, until I see
concrete examples of how x:data could be improved. And, it would have been
nice to see those comments during the previous JEP process.
> That the JEP cleary states "A node owner must be able to configure a
> node." and that you've clearly stated "Nodes MUST be
> configured using x-
> data". (Ofcourse you've toned this down a little now).
> That this means you've basically said: if you make an implementation
> that does not use x:data to configure nodes you do not use
> JEP-0060 for
> your PubSub.
particularly if you ignore PGM's potential compromise, it says that.
More information about the Standards