[standards-jig] comments on JEP-0060
thoutbeckers at splendo.com
Fri Jan 17 18:03:10 UTC 2003
"Peter Millard" <me at pgmillard.com> wrote on 17-1-2003 18:51:09:
>Tijl Houtbeckers wrote:
>> I've been reading through JEP-0060 and it looks like a good place to
>> start for a very decent PubSub system. It seems to consist however
>> out of two different kinds of examples. One group is the examples of
>> generic pubsub queries (publish, subscribe, etc.) while the other
>> group is examples of a specific (non-generic) implementation of the
>> pubsub component that uses x:data.
>[Much more stuff snipped..]
>Apparently, the JEP needs to be more clear about the x-data examples
>shown in the JEP. Here are some things that I need to elaborate more
>1) Nodes MUST be configured using x-data (similar to room
>configuration in JEP-45/MUC).
Ok, then this was my first mistake. When I read the line "This Jabber
Enhancement Proposal attempts to document a single cohesive, generic
protocol which all forms of pub-sub can utilize." and then saw x:data
stuff inthere it had me kind of worried. I still found it unlikely that
x:data was mandatory for a *generic* PubSub protocol. Upon further
inspection I saw that's it's used mostly just for configuring
This made doubt about just how much of a requirment x:data is. I
discussed it with Ralph Meijer (who uses JEP-0060 for his RSS delivery
system) and we both agreed it's unlikely that x:data is an actual
requirment. To me that means it wouldn't be part of a generic PubSub
component either. (Sorry for draggin' you into this Ralph ;)
>2) Implementations may use & implement ANY configuration options deemed
>necessary for normal usage by consumers of that pub-sub component.
>3) See section 3 of the JEP for the MUSTs and MAYs applicable.
Apperently I was wrong in that assumption :( since you state here
"Nodes MUST be configured using x-data". Just saying that isn't very
clear either. Does it mean we have to support the x:data forms as shown
in the example, or as a superset? Or can we use any x:data form we like?
(from your answer below I'd say any kind of x:data form can be used).
In both cases, it's a very strict requirment, espc. if you say "nodes
*MUST be configured* using x:data" rather than "nodes *MUST be
configurable* using x:data".
What it comes down to is: in both those cases, I don't see anything
generic about using x:data to configure your PubSub component (nodes),
let alone *restricting* it to x:data. To put is short: why can't I
build a PubSub component that uses a web interface? Or plain jabber
messages? Or use my own XML format? x:data forms by their nature are
more human readable then machine readable. I don't see why it should be
restricted to that, and I don't see why I should be forced to use
x:data at all.
Based on the JEP and what you said here this leads me to believe that
the JEP is not clear on this point at all. All it says is "A node owner
must be able to configure a node.", wich is very vague. If I have to
add to that what you say here: "Nodes MUST be configured using x-data"
(or the toned down version "must be configurable"), that means that
either this JEP is not about a generic pubsub model, or it is about a
(imho) bad generic model.
Because I refuse(d) to believe the second, I assumed in my first mail
that the use of x:data in the examples are examples of an
implementation, not the generic protocol. Just to be sure, I mean the
fact that x:data is used, not just the choosen configuration options.
>I want this JEP to show what are POSSIBLE configuration options for
>pubsub nodes and definitely don't want to see this split into multiple
Well if it's part of the protocol it should be there. I refuse to see
this as a JEP for generic PubSub then, since this is to me very clearly
a design decision.
>It was never the intention of this JEP to be an information draft
>of an existing implementation. The converse is actually true.. the new
>pubsub component on js.org is "mirroring" this draft as it progresses..
> much like the mu-conference component did while JEP-45 was being
If you want real world examples, Ralph's RSS delivery service (it's the
best thing since sliced bread I tell you!) does not use x:data to
>I would encourage you to send the list some alternate verbiage that
>would make the points that you feel are more "informational"
>explicitly state that they are "optional". I will also be working on
>making this more clear.
To me *any* use of any x:data at all in PubSub is a design decision. It
does not belong in a generic PubSub protocol. However in the current
JEP the stuff is all over the place, right inbetween all the other
examples. There is not made a clear distinction between them at all.
I think it would greatly benefit the JEP if you'd.. well.. agree with
me ;) that using x:data is not part of generic PubSub. If you split
them , not only would it make the JEP more generic, it would also make
it a lot easyer to read and understand, espc. for client developers. If
you agree at least a bit with me you'd at least seprate the two within
the document, or make the difference between them suffienctly clear.
Seeing where you currently stand.. ("Nodes MUST be configured using x-
data (similar to room configuration").. Does anyone else have an
opinion this subject?
PS: To make sure noone gets me wrong, I have nothing against an
implementation that uses x:data for these things, it can be very
usefull espc. if humans administer the component. It's just that I can
think of other situations where a different model could be much more
usefull. Other then this point I think it's a great JEP for those
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards