[standards-jig] comments on JEP-0060

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Jan 17 22:26:53 UTC 2003


"Peter Millard" <me at pgmillard.com> wrote on 17-1-2003 23:18:15:
>
>Tijl Houtbeckers wrote:
>> "Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com> wrote
>>> 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.
>
>I agree with this point and will re-phrase accordingly.. What I wanted 
>to to convey was:
>* 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.
>
>> As PGM stated the x:data form can be *any* x:data form. Basically 
>> that means it's only humanreadable.
>[LATER]
>> I don't see how x:data is machinereadable unless you have some very
>> fancy AI or if you know exactly wich fields are in the form. If you
>> standardize on wich fields to use (from what PGM says this is not the
>> case I think) why use x:data at all?
>
>What are you talking about? Doesn't strcmp work anymore?? I don't 
>recall implying that var names for the x-data fields could never be 
>fixed. 

If they're fixed.. then where does it say how it's fixed? It's not in 
the JEP, and you said yourself it could be *any* configuration. Let's 
suppose they are.. apart from the fact that this is an, in my opinion, 
odd usage of x:data. But let's suppose I can accept that ;) I'm 
struggeling to see how this is "generic" concering PubSub, since you'll 
still have to decide wich str's you're going to strcmp with. 

I don't know exactly how you're gonna document this. For XML they have 
this thing called DTD for that. Maybe we should try to describe using 
x:data wich x:data field are allowed eh? 

>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)

>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 magnets. 
A truly generic spec. will allow all of those. 

>Also, we have yet to establish the process for where 
>things like var attributes in x-data forms get documented... Maybe 
>they should be documented in the JEP. 

But it's not there yet (2).

>> I don't see why my PubSub server should have the ability to
>> communicate with humans. Sure it's nice on some occasions but why
>> make it a requirment? And why would the Council want to restrict my
>> choices like that?
>
>What the heck are you smoking?? 

sjees! (geddit?)

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

>The requirement is 
>that a node be configurable (discussed above), and that configuration 
>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? 

>I just don't see the need to create yet another 
>protocol for describing a generic data set (which is what any 
>configuration DTD/schema would look like for pubsub). 

Again, I'm not saying for some PubSub components using x:data is a bad 
idea. But it's not about "some PubSub" component, it's about a generic 
PubSub component. 

>I don't proclaim 
>to know ALL of the possible configurations for a pubsub system.. Do 
>you? ?? Using x-data is the only real-world solution we have for 
>solving the configuration options problem TODAY.

I don't claim I do either. I do not all of them are fixed with x:data. 
Surtenly not in it's excisting state (I asume you didn't write this JEP 
in the future). Maybe in the future with some hacks you can get it done.
 If that's a good idea is another thing. 

I suggest that we leave this free to the implementation. This way we 
cover "ALL of the possible configurations for a pubsub system". x:data 
is one of the possible configurations. It's NOT the generic solution. 
You can *perfectly* document your x:data usage without screwing with 
the generic JEP. 

>Also regarding the "communicate with humans" issue... People have been
>clamoring for pubsub implementations that clients can start to utilize.
> I want to be able to publish an avatar, web news, my pgp key, web 
>service pointers, etc... Why would humans never want to interact with 
>a pubsub system???? 

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

>This is not what every jabber list and website has 
>been saying for the past 18 months. If you're talking about _YOUR_OWN_ 
>implementation, then lock down the creation of nodes to specific JID's 
>and respond to configuration requests with an iq-error.

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. 

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. 

>As soon as I get some more IRL bandwidth, I'll be working on a new 
>revision of the JEP with the change noted above as well as some other 
>comments I've received.

Then I urge you to think over: 

What's the benefit of forcing PubSub implementers to use x:data for 
machine<->machine communication? Wich Should Lead To Making a 
*seperate* JEP that specifies how to use x:data to configure your type 
of PubSub component (yes I don't give up easy do I?). If that's 
impossible, to use the x:data examples in the JEP as examples of how it 
could be done rather then how it MUST be done. 

Picking up smoking, so I can say "what the heck are you smoking?" when 
I don't like your next revision :P 

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




More information about the Standards mailing list