Re: [Owfs-developers] Extend OWFS to other Devices

[Jerry Scharf]

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> >  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.
> --

Re: [Owfs-developers] Extend OWFS to other Devices

[Eloy Paris]

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  > 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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Roberto Spadim]

here is some data format... we could use owfs format...
http://owfs.org/index.php?page=structure-directory

owread /structure/10/temperature
check that we could call a program... PROGRAM READ /structure/10/temperature
we could use the same parameters of owread and owwrite...

t,00,01,ro,12,v,FILE_NAME,FILE_VALUE
t->type...
00-> ?? index
01-> ?? elements
ro -> access
12 -> size
v -> changeability

FILE_NAME -> file name (new)
FILE_VALUE -> file value (new)

?? = i don´t know if it´s a bit complicate to interface this type of information

-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial

--
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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Roberto Spadim]

i have some ideas, maybe could not work maybe could...
i was reading http://owfs.org/index.php?page=external-sensor-design


Configuration will be by text files
Two layers of config
First layer has the list of devices (unique names)
Second layer describes the device's family


i was thinking with another idea
we could have a READ and a WRITE call, and a interface file to
add/remove programs/directories
for example...

echo "new_interface /bin/program" > /external/add_interface_file
(this file allow add new directory to /external for example)
echo "new_interface" > /external/del_interface_file  (this file allow
delete a directory /external/new_interface for example)

when aceess /external/new_interface/
it call /bin/program read /

program return a csv file...
string;10;abcdefghij
int;1;a
float;3;fil
directory;1;a
type;size;value

owexternal interpret the file and create owfs 'files/directories'...

if we read a file...
it call /bin/program read /a

it return a csv file too...
int;1;1234


when we write...
it call /bin/program write /a value
return the read value too or maybe with information about error (not
writeable file), or 'OK', or 'wrong data format' or 'type mismatch',
or other error

we could return more information at csv file...
writeable, static, cacheable, etc...

but the main idea is...
a interface file to add/delete programs and directory /bin/sh ->
owfs directory /external/directory

and owexternal just call /bin/sh READ /path, or WRITE /path VALUE
to change informations

that´s what we are trying to implement?

-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial

--
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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Roberto Spadim]

don´t forget to allow owhttpd work with it too
it´s very nice the idea of making a modbus program and interface it
directly with owhttp allowing a json interface to javascript 

Em 29 de fevereiro de 2012 00:33, Roberto Spadim
 escreveu:
> very very nice!!!
> maybe we could use json or another language to send and receive informations?
> maybe a txt or csv or xml(i don´t like xml... txt and csv can run in
> any bash program, json is more usable in php,perl,python scripts)
>
> do you have any idea about the implemention?
>
>
> Em 29 de fevereiro de 2012 00:17, Paul Alfille
>  escreveu:
>> 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).
>>
>> 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  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.
>>>
>>>
>>>
>>> --
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> ___
>>> Owfs-developers mailing list
>>> Owfs-developers@lists.sourceforge.net
>>> 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
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial

--
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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Roberto Spadim]

very very nice!!!
maybe we could use json or another language to send and receive informations?
maybe a txt or csv or xml(i don´t like xml... txt and csv can run in
any bash program, json is more usable in php,perl,python scripts)

do you have any idea about the implemention?


Em 29 de fevereiro de 2012 00:17, Paul Alfille
 escreveu:
> 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).
>
> 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  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.
>>
>>
>>
>> --
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> ___
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> 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
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial

--
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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Paul Alfille]

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).

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  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.
>
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> 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
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[ekgnkb3d]

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.


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Eloy Paris]

On 02/27/2012 09:13 PM, Paul Alfille 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?

Yes! Seems like a fantastic idea. Would allow people to build sensors 
that use whatever protocol and hardware interface they wish to use to 
communicate with the PC world and still use the owfs interface they are 
used to for 1-Wire devices.

Eloy Paris.-

>
> On Mon, Feb 27, 2012 at 5:29 AM, ekgnkb3d  > wrote:
>
>
> Hi all,
> beside using 1-Wire devices I would like to use other sensors as well.
> Currently I play with an temp-sensor getting data very simple by a
> serial
> port.
>
> So writing all this polling, retry, alias, fuse (and a lot of other
> functionality) again is a lot of effort - so maybe there is a way to
> extend
> the existing OWFS framework by own devices. E.g. some simply C
> program or
> scripting would be great and at the end the sensor could be accessed via
> owserver and appear as HTTP, file-system or CAPI
>
> Is this somehow possible and documented?
>   Achim
> --
> View this message in context:
> 
> http://old.nabble.com/Extend-OWFS-to-other-Devices-tp33398846p33398846.html
> Sent from the OWFS - Dev mailing list archive at Nabble.com.
>

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Re: [Owfs-developers] Extend OWFS to other Devices

[Paul Alfille]

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?

On Mon, Feb 27, 2012 at 5:29 AM, ekgnkb3d  wrote:

>
> Hi all,
> beside using 1-Wire devices I would like to use other sensors as well.
> Currently I play with an temp-sensor getting data very simple by a serial
> port.
>
> So writing all this polling, retry, alias, fuse (and a lot of other
> functionality) again is a lot of effort - so maybe there is a way to extend
> the existing OWFS framework by own devices. E.g. some simply C program or
> scripting would be great and at the end the sensor could be accessed via
> owserver and appear as HTTP, file-system or CAPI
>
> Is this somehow possible and documented?
>  Achim
> --
> View this message in context:
> http://old.nabble.com/Extend-OWFS-to-other-Devices-tp33398846p33398846.html
> Sent from the OWFS - Dev mailing list archive at Nabble.com.
>
>
>
> --
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers