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: > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 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 [EMAIL PROTECTED]/vertical.ch1.scale. I was going to write a client for [EMAIL PROTECTED] 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 _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
