[jdev] Data forms, jabber:iq:register, jabber:x:data and the <x/> tag

[Dr. Craig Hollabaugh]

On Tue, 2004-03-30 at 11:28, Peter Millard wrote:
> > Question 2: Did the Jabber architects intend to map 'service discovery
> > node feature vars' to 'data form field vars'?
> 
> Yes.

very nice, good work.


> >  a. live with <x/> extention approach of Data Forms and the
> > jabber:iq:register namespace
> 
> Yes. Ideally, you could use adhoc-commands, but you'll need to convince client
> developers to add support for it. You could always do both. If I understand you
> correctly, you want to use iq:register to "SET" values on the various devices.
> Instead of using a node attribute to do this, simply include a hidden field in
> the x-data form that has that value. When a client submits the register back to
> you, that hidden value should be included in the response. 

Excellent idea? However, I still need a logical way to discover the
hierarchical node tree of a field device. Having a form with hundreds of
fields will be overwhelming. So could I discover the nodes (which
contain an entry for this hidden field) then use iq:register with a
hidden field to remap things back together.


> The other way around
> this, would be to map the device-id's to "user" part of a JID: like this:
> 
>     vertical.ch1.scale at scope1.foo.org

Let's talk about this, this would lead to thousands of jids, a scope
alone has a couple hundred values, so you'd end up with

vertical.ch1.scale at scope1.foo.org
vertical.ch2.scale at scope1.foo.org
vertical.ch3.scale at scope1.foo.org
etc.

This seems like a mess from my limited jabber coding experience. I'm
using python and from what I've done, I'd have to start up a thread to
handle communications for each of these jids, not to mention that all
these need to registered on the server. I suppose there's a better way
of doing this. I'm all ears, I'm looking for simplisticity.

I first started out thinking that I could use the resource in a JID like
scope1 at foo.org/vertical.ch1.scale. I was going to write a client for
scope1 at foo.org and looked at the resource to figure out what to do. I
quickly found out that the server rewrites the complete jid, ignoring
what I specified in the from attribute.

> This is essentially what adhoc commands is. You just need more widespread
> support in clients.
> 
> Hope this clears some things up.

Yes, this definately helped. I'll re-read the ad-hoc commands again and try to
piece in this conversation. 

Ultimately, one my research goals is to determine bandwidth utilization of 
XML protocol for instrumentation. My architecture will inform 
listeners/subscribers of any field device parameter change (either through 
network commands or front panel operation) via asynchronous messaging. Instead of 
continuous polling, sub-systems will just get update messages if something has
changed.

I haven't figured out how to distribute these update messages either. Fortunately,
the Jabber environment offers several options to send value information including
presence via <x/>, chat room message with value info in <x/>, and pubsub. Any other 
ideas?

Thanks again for your comments.
Craig