[standards-jig] comments on JEP-0060

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Fri Jan 17 20:00:22 UTC 2003

I would disagree that x:data makes JEP-0060 less generic.  It is a
design decision, but a decision is necessary.  Nodes need configuration,
and x:data does a fairly handy job of it. Some LCD (lowest common
denominator) needs to be agreed upon, or there will be little hope for

IMO, x:data is a good LCD.  x:data is a good balance between
human-readable and machine-readable requirements, it's Jabber-centric
(as is this Pub/Sub spec), it's "ACTIVE", and it's supported by a fair
number of clients and components.

I can see your point on the difference between "Nodes MUST be
*configured* using x-data" and "Nodes MUST be *configurable* using
x-data", though.  If the publisher can support other configuration
mechanisms *in addition to* x:data, that's fine with me, and is probably
acceptable to the Council as well.

-  LW

On Fri, 2003-01-17 at 10:03, Tijl Houtbeckers wrote:
> "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. 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)

More information about the Standards mailing list