headers
Vincent Danjean | 1 Apr 2011 11:11
Picon
Favicon

Re: Aliases on DS18B20

On 31/03/2011 22:04, Paul Alfille wrote:
> One thing I didn't mention in the 2.8p8 release notes is that there is
> a new "/settings/alias/list" that gives the sn=alias\n list. It should
> be in format suitable for an alias file.
> 
> Probably writing a "" (zero length string) would remove an alias and
> writing an alias would add an alias.
> 
> Are you sure we need multiple aliases for the same device? It adds
> some complexity.

For myself, I'm questioning the use of alias at the low-level interface.
The advantage is that, if aliases are visible here, all high-level interface
will automatically see them.
However, this means a non-uniform way to access sensors for automatic
scripts. Moreover, current aliases does not hide the topology of the
1-wire network (in case of use of 2409 for example), still requiring that
user know on which branch the sensor in plug-in.

What about setting up one (or two for uncached access) special directory
(/aliases and /uncached/aliases ?) where the content are 'shortcuts' (can be
symlinks on owfs or plain directory for owserver, owhttpd, ...) to sensors
or even to property of sensor. This idea would be that any path under
/aliases would be managed as if the target has been given.
  The availability of /settings/alias/list means that the 'alias' property
is not really required (the same info can be got from the new file), so it
can be removed.
  And some special /settings/alias/{add,remove,rename} file, write-only,
could be used to manage these aliases.
  Future development can allows to have subdirectories under /aliases
(Continue reading)

Permalink | Reply | 9 comments |
headers
Vincent Danjean | 1 Apr 2011 12:07
Picon
Favicon

RFC: a new 'ls -l' like command ?

  Hi,

  I would like to propose a new command for owserver. Currently, when
we want to list directories, several commands are available, at least
DIR and DIRALLSLASH. Moreover, we can use flags in the command to
add (or not) to the listing system files.
  If a software want automatically scan a directory and know which
kind of files are present, it needs at least two invocations of
DIRALLSLASH to discove the properties of directory entries (system or
not, directory or file). And some other properties are known by
owfs but cannot be discovered by software. I mean:
- is the file readable ?
- is the file writable ?
- can the file contents change ? (never for the 'type' property for example)
- what is the type of the data ? (float, int, string)
- ...

  I can think of this kind of flags:
r: readable
w: writable
d: directory (R/W does not apply ?)
i: immuable (contents never changes)
s: system file
ti: contents is always an integer
tf: contents is always a double
ts: contents is a string
l: this file is a link (ie alias)

  The format of the answer can be problematic if all POSIX filename are
allowed for aliases and if we want a ASCII answer. A possible format would
(Continue reading)

Permalink | Reply | 14 comments |
headers
Paul Alfille | 1 Apr 2011 13:00
Picon

Re: Aliases on DS18B20

Very interesting ideas.

My proposal:
1. Only one alias per slave (serial number)
2. Aliases can be added/changed by:
    A. writing to 10.12312300/alias (if the device exists)
    B. writing to settings/alias/add
3. A blank name is equivalent to removing
4. Names can include any char except a null, \r, and \n (0x00, 0x0A and 0x0D)
5. Aliases will not be persistent across restarts, but you can always
store /settings/alias/list and feed it back.
6. Aliases are shown by default, except if the /unaliased directory is requested

Reasoning:
1. Multiple aliases per SN makes the back-replacement of a serial
number by an alias indeterminate, makes the 10.12312300/alias property
had to format, and makes the length of an alias field indeterminate.
2. Writing to an alias field that doesn't exist requires too many
changes in the path parsing code
3. We don't use delete anywhere else in OWFS, although it is
consistent with the filesystem metaphor. A blank write is unambiguous.
4. I'm open to different restrictions on names, but this is supposed
to be a convenience, for easy human-readable names. Too awkward a
syntax defeats the purpose.
5. I don't want to court the security problems of a persistent
database storage (we currently only write to one file, the PID file,
and only once at startup).
6. This will be backwards compatible with current behavior. Arguably
makes the expected/desired behavior the default behavior ("Show the
aliases, since I went through the trouble of creating them!"), and
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Alfille | 1 Apr 2011 13:04
Picon

Re: RFC: a new 'ls -l' like command ?

Have you looked at the "structure" entries? Does it give you the
information you need? Otherwise, I think your idea has merit. This
information could be included in every owserver response (with a bump
in protocol number and preserving backwards compatibility).

Paul Alfille

On Fri, Apr 1, 2011 at 6:07 AM, Vincent Danjean <vdanjean.proj <at> free.fr> wrote:
>  Hi,
>
>  I would like to propose a new command for owserver. Currently, when
> we want to list directories, several commands are available, at least
> DIR and DIRALLSLASH. Moreover, we can use flags in the command to
> add (or not) to the listing system files.
>  If a software want automatically scan a directory and know which
> kind of files are present, it needs at least two invocations of
> DIRALLSLASH to discove the properties of directory entries (system or
> not, directory or file). And some other properties are known by
> owfs but cannot be discovered by software. I mean:
> - is the file readable ?
> - is the file writable ?
> - can the file contents change ? (never for the 'type' property for example)
> - what is the type of the data ? (float, int, string)
> - ...
>
>  I can think of this kind of flags:
> r: readable
> w: writable
> d: directory (R/W does not apply ?)
> i: immuable (contents never changes)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Marcus Priesch | 1 Apr 2011 13:13
Picon

Re: Aliases on DS18B20

Am Freitag, den 01.04.2011, 07:00 -0400 schrieb Paul Alfille:
> I'm still a bit concerned about the potential problems a rogue user
> can cause. There is no limit to the storage that can be required.

why not allow "dynamic" adding at runtime only for ow-id's that acually
currently exist on the bus ... 

imho if one wants to "provision" her owserver with aliases for sensors
that arent connected already - then it could/should be done only with an
alias file ... 

i wonder how long it would take before someone comes up with need for
support for i18n'ed aliases ... ;)

regards,
marcus.

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
Permalink | Reply | 2 comments |
headers
Vincent Danjean | 1 Apr 2011 13:31
Picon
Favicon

Re: RFC: a new 'ls -l' like command ?

On 01/04/2011 13:04, Paul Alfille wrote:
> Have you looked at the "structure" entries? Does it give you the
> information you need? Otherwise, I think your idea has merit. This
> information could be included in every owserver response (with a bump
> in protocol number and preserving backwards compatibility).

I did not look at the structure directory. Indeed, there is lots
of useful doc. In there a documentation somewhere about the meaning
of the contents of the files under this directory ?
  I will look at this and see if my proposal is still useful or not.

  Regards,
    Vincent

> Paul Alfille
> 
> On Fri, Apr 1, 2011 at 6:07 AM, Vincent Danjean <vdanjean.proj <at> free.fr> wrote:
>>  Hi,
>>
>>  I would like to propose a new command for owserver. Currently, when
>> we want to list directories, several commands are available, at least
>> DIR and DIRALLSLASH. Moreover, we can use flags in the command to
>> add (or not) to the listing system files.
>>  If a software want automatically scan a directory and know which
>> kind of files are present, it needs at least two invocations of
>> DIRALLSLASH to discove the properties of directory entries (system or
>> not, directory or file). And some other properties are known by
>> owfs but cannot be discovered by software. I mean:
>> - is the file readable ?
>> - is the file writable ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Danjean | 1 Apr 2011 14:11
Picon
Favicon

Re: Aliases on DS18B20

On 01/04/2011 13:13, Marcus Priesch wrote:
> Am Freitag, den 01.04.2011, 07:00 -0400 schrieb Paul Alfille:
>> I'm still a bit concerned about the potential problems a rogue user
>> can cause. There is no limit to the storage that can be required.
> 
> why not allow "dynamic" adding at runtime only for ow-id's that acually
> currently exist on the bus ... 

It can be a good limitation : an admin can limit who is able to run
the owfs server (with a non restricted alias file). And, at run time,
only existing chip can be aliased.

> imho if one wants to "provision" her owserver with aliases for sensors
> that arent connected already - then it could/should be done only with an
> alias file ... 
> 
> i wonder how long it would take before someone comes up with need for
> support for i18n'ed aliases ... ;)

I see aliases as a 'extended' programmer interface, not really as a
user interface. I think that i18n should be addressed on top of this
API (and, for me, aliases are border-line wrt interface level).

  Regards,
    Vincent

> regards,
> marcus.
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Danjean | 1 Apr 2011 14:20
Picon
Favicon

Re: Aliases on DS18B20

On 01/04/2011 13:00, Paul Alfille wrote:
> Very interesting ideas.
> 
> My proposal:
> 1. Only one alias per slave (serial number)
> 2. Aliases can be added/changed by:
>     A. writing to 10.12312300/alias (if the device exists)
>     B. writing to settings/alias/add
> 3. A blank name is equivalent to removing
> 4. Names can include any char except a null, \r, and \n (0x00, 0x0A and 0x0D)
> 5. Aliases will not be persistent across restarts, but you can always
> store /settings/alias/list and feed it back.
> 6. Aliases are shown by default, except if the /unaliased directory is requested

How do you mix /unaliased and /uncached ? There will be an
/unaliased/uncached or an /uncached/unaliased ?

With your proposal, you still alias only chip (not individual properties) ?
And, in case of topology (DS2409), you still need to look into the correct
branch ?
[both are not really a problem from my point of view but I want to
be sure that nobody really ask for this]

  Regards,
    Vincent

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and
(Continue reading)

Permalink | Reply | 3 comments |
headers
Roberto Spadim | 1 Apr 2011 15:07
Picon

Re: RFC: a new 'ls -l' like command ?

check ownet.php there's something about it too, it check not only one
file, but have a cache about file informations (types)
the information about files must be compatible with FUSE must check
fuse docs and see what can be done

2011/4/1 Paul Alfille <paul.alfille <at> gmail.com>:
> Have you looked at the "structure" entries? Does it give you the
> information you need? Otherwise, I think your idea has merit. This
> information could be included in every owserver response (with a bump
> in protocol number and preserving backwards compatibility).
>
> Paul Alfille
>
> On Fri, Apr 1, 2011 at 6:07 AM, Vincent Danjean <vdanjean.proj <at> free.fr> wrote:
>>  Hi,
>>
>>  I would like to propose a new command for owserver. Currently, when
>> we want to list directories, several commands are available, at least
>> DIR and DIRALLSLASH. Moreover, we can use flags in the command to
>> add (or not) to the listing system files.
>>  If a software want automatically scan a directory and know which
>> kind of files are present, it needs at least two invocations of
>> DIRALLSLASH to discove the properties of directory entries (system or
>> not, directory or file). And some other properties are known by
>> owfs but cannot be discovered by software. I mean:
>> - is the file readable ?
>> - is the file writable ?
>> - can the file contents change ? (never for the 'type' property for example)
>> - what is the type of the data ? (float, int, string)
>> - ...
(Continue reading)

Permalink | Reply | 11 comments |
headers
Roberto Spadim | 1 Apr 2011 15:21
Picon

Re: Aliases on DS18B20

> 1. Only one alias per slave (serial number)
i think we could have a `table` just for symlinks like a filesystem,
it's more flexible

>    A. writing to 10.12312300/alias (if the device exists)
nice! no symlinks :) heeh just

echo "alias1/alias2/aliaas3/alias4" > 10.12312300/alias
want remove? echo again:
echo "alias1/aliaas3/alias4" > 10.12312300/alias
what get alias? cat
cat 10.12312300/alias

> 3. A blank name is equivalent to removing
:/ maybe maybe make 10.12312300/alias a directory
10.12312300/alias/alias_name1
10.12312300/alias/alias_name2
10.12312300/alias/alias_name3
10.12312300/alias/alias_name4 ....

> 4. Names can include any char except a null, \r, and \n (0x00, 0x0A and 0x0D)
we will have problem with FUSE interface "/" isn't allowed, "\\" is
dangerous for windows users (owfs over samba or over nfs)
" " are accept with: "\ "

> 5. Aliases will not be persistent across restarts, but you can always
> store /settings/alias/list and feed it back.
may only one file with all alias is easier to backup / restore with
this it's persistent on restarts (with some others programs/scripts)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane