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

[Peter Millard]

Dr. Craig Hollabaugh wrote:
> On Tue, 2004-03-30 at 11:28, Peter Millard wrote:
>> 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.

Correct... however, I think the jid solution (below) is a better idea.
Specifically, I'm not sure how the client would send the initial
jabber:iq:register "get" request would include the proper hidden field.

>> 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
[SNIP]
> 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.

You want a single component: scope1.foo.org which would handle packets for ALL
jids at that domain. (*@scope1.foo.org). You'd have a different component for
each device. I suppose, you could also multiplex multiple devices to a single
component by doing:

scope1.vertical.ch1.scale at devices.foo.org

The idea with components is that they communicate directly with the jabberd
server (the router) using a socket. Jabber routers always route by 'domain' so
any packets destined for your domain will land at your component. You do the
right thing based on the full jid then. This is exactly how MUC components work
(room at conference.jabber.org) for example. JEP-114 is a document which describes
the handshaking you need to do in order to connect a component to a jabberd
1.4.x server. Jabberd2 works slightly different, and docs for that should be on
jabberd.jabberstudio.org someplace. (Rob would have a better idea.. rob?)

[SNIP]

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

Seems like what you really want here is pubsub and a client which can do some
cool GUI stuff with the data.

pgm.