[standards-jig] comments on JEP-0060

Tijl Houtbeckers 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 
>about: 
>
>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 
(thankfully). 

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 
>JEPs. 

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 
>drafted. 

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 
configure nodes. 

>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 
things too. 


-- 
Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands




More information about the Standards mailing list