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

Dr. Craig Hollabaugh craig at hollabaugh.com
Wed Mar 31 16:22:53 CST 2004

On Tue, 2004-03-30 at 17:20, Peter Millard wrote:
> 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. 

Hmmm, let me think about that. I'll see how that fits in.

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


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

That's the plan actually. The GUI is completely dynamic depend upon what
it discovers. Year after year, a tremendous amount of effort is put into
GUI design for instrumentation. My research project is looking at
eliminating this type of development and build GUIs on the fly. 

Dr. Craig Hollabaugh, craig at hollabaugh.com
Author of Embedded Linux: Hardware, Software and Interfacing

More information about the JDev mailing list