Paul and Eloy, I don't have an opinion whether the external devices should be added to the main list in the long run, but given the potential cost of doing an directory listing, this may be a wise precaution. Having an /external directory for these may be the right way to go until we learn more about how these work in practice. Folding these devices into the main directory is an easy thing to add as an option down the road.
I agree with using a bus.external.n model. This would have two big advantages for me. It would hopefully allow owserver to act as an aggregator for 1-wire and external devices, much as I use it today to synthesize different 1-wire masters and provide a single point for all my other software. You have said that the external interface programs will use oswerver protocols to work, so why not keep the bus model intact? Second, it allows me to manage things like directory actions and controls like simultaneous (should that make sense) on a per external interface basis. It might be nice if there were some bus level configuration that can then be added to the per family properties and shown at the bus level. Again I am looking at simultaneous as a representative function. Programmtic control of caching might be another example of a bus level control. I use simultaneous conversion at the bus level as a significant part of what I do, so it impacts how I think about this. jerry On 03/02/2012 10:25 AM, Eloy Paris wrote: > 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 ------------------------------------------------------------------------------ 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
