Hi Paul, On 02/28/2012 10:17 PM, Paul Alfille wrote:
> Ok, these are the design notes so far: > http://owfs.org/index.php?page=external-sensor-design > > I'm only so-so happy with the "external" name for the program > (owexternal) and directory (/external). What about using different "buses" for external, non-1-Wire devices? For instance, we could go with /bus.externalN (for example, "/bus.external0"). If different "extensions" were in use, and the "owexternal" program needed to talk to different interfaces to obtain the data (IPC, an external data grabber program, etc.), then somehow we could have different "buses" (e.g. "/bus/external0", "/bus/external1", etc.) In any case, even if it is not feasible/applicable to have different "buses", then you might like "/bus.external" better than "/external", the implication being that it is a non-1-Wire "virtual bus", not a physical one. Sorry, I wrote the above before realizing that you have this in the design notes, so the above may not apply, or it may already be addressed: "Devices will require unique names, but exist in a different "name space" from standard 1-wire devices to prevent confusion. Devices will be in /external directory All external devices will be in the same directory (like 1-wire) but can be pieced out by the "bus.x" structure" Is there really a need to put external devices in its own, separate directory? I wouldn't mind seeing 1-Wire devices alongside external devices. If I want to only look at 1-Wire devices then I'd look in the bus.n directories. Do understand the design notes correctly if I state that owserver will not be modified to talk to external data providers but that there will be a new program (owexternal) for this function? If so, will there be a need to call owfs to mount the "external" bus in a different location in the filesystem? Cheers, Eloy Paris.- > > All the configuration files are a bit of a nuisance, but we really have > two things: > Family types (defining a type of sensor) > Individual sensors (unique addresses) > > In 1-wire the list of sensors can be discovered by searching the bus, > and the family type (and supported properties) are hardcoded. > > My thought is to make the extension system very flexible at the start. > If there are classes of devices that have similar ability to be either > auto-discovered or self-describing, that can be supported later by a > special version of owexternal. > > On Tue, Feb 28, 2012 at 4:07 AM, ekgnkb3d <[email protected] > <mailto:[email protected]>> wrote: > > > > Paul Alfille-2 wrote: > > > > Interesting idea. I've been tempted to build a special owserver > that has > > plug-in sensor code -- owexternal. > > > > The plug-in would get a separate mane space (perhaps > > /external/sensor43/humidity) and have to report a few properties like > > length, type, read/write and volatility. > > > > Plugins could be written in a variety of languages, and the owserver > > protocol would be handled by owexternal. > > > > Is there interest in this? > > > > > > ...a simple: "Yes" :jumping: > -- > View this message in context: > > http://old.nabble.com/Extend-OWFS-to-other-Devices-tp33398846p33405330.html > Sent from the OWFS - Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
