Changes
Under the barbarian name of XMPPHWFS stands the following idea:
'''hardware IOs made available''' (on a fuse filesystem) '''through xmpp messaging protocol'''. The latest idea is to use fuse only as on option, so the name will definitely change a bit. ''locmon2'' seems like a good candidate to me.
XMPPHWFS is meant to replace [http://david.lutolf.net/dt/locmon locmon], which in my opinion was a good idea but is too buggy and impractical. from a recent copy of ''20 minutes'', it seems the industry is also heading towards something alike, only for home robots and social networking. WTF, tell me why your vacuum cleaner should tell all your facebook friends there's a plant in its way. Any suggestions are welcome, coding has not really started yet anyway.
[[Image:Xmpphwfs arch.svg|thumb|XMPPHWFS architecture]]
* Debugging new hardware is simply done through communication with a human client.
* ''corecode'' suggest to use the [http://xmpp.org/extensions/xep-0060.html PubSub] [http://jabber.org/protocols/pubsub mechanism] for event notification, I think he's bloody right on this. Some bot can catch these events and update the cache DB as well.* GUI can also be implemented as a bot (ctrl_bot?). Simple and clean. Use a of a cache DB is a good idea to minimize traffic and load on HALs. For the interface, I'd suggest HTML with Ajaxwith templates and possibility to include content like webcams and the such. Help is needed here.* some other bot (log_bot?) can generate [http://oss.oetiker.ch/mrtg/MRTG MRTG graphs] and update the cache database on the same occasion. MRTG config can of course be generated automatically and graphs included in the GUI.* The Fuse inteface, if needed, should also be implemented as a bot. Simply specify where to mount the filesystem, connect your bot, you're done. No need to have a modified jabberdand the resulting filesystem can be mounted on any host. Any interface of this type (read: local interface, as opposed to html-based) should not talk directly to HALs, but communicate with a bot (ctrl_bot?) that has access to the cache database.
it was suggested to use IRC for communication, but device description is be greatly improved through use of XML and XMPP is just that.AFAIK, IRC does not have a PubSub mechanism. :I've been dreaming of a 3D GUI where you can walk around and interract with the hardware in a natural fashion. Volunteers?
== Device description ==
Since XMPPWHFS is aimed towards real-world I/Os, for each variable we need lots of useful info such as:that must be made available by each HAL=== About the HAL ===* name* description* location (GPS coordinates and/or description)* icon? I think we don't really care about the HAL itself, it's just a way to conveniently group I/Os === About devices on each HAL ===
* variable name
* variable type and allowed values (int, float, enum..)
* I/O type (lock, temperature, humidity...). a more or less standard list must be written
* ro/rw flag
* unit (meters, seconds, °C..)
* update delay in seconds
* last update timestamp
* variable type and allowed values (int, float, enum..)warn/alarm thresholds for event notification* icon? maybe not necessary. one can be chosen from the I/O name or type (door, temperature, humidity...)* location (GPS coordinates and/or description)* text/blob, possibly containing icon* min/max trigger values
=== Sample session ===
