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. ([EMAIL PROTECTED]). 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: > > [EMAIL PROTECTED] > > 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 > ([EMAIL PROTECTED]) 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, [EMAIL PROTECTED] Author of Embedded Linux: Hardware, Software and Interfacing www.embeddedlinuxinterfacing.com _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
