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

[Dr. Craig Hollabaugh]

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

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
www.embeddedlinuxinterfacing.com