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
matches uncached semantics.
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.
# Run-away example
# 2^56 entries
for a in 0 1 2 3 4 5 6 7 8 9 A B C D E F ; do
for b in 0 1 2 3 4 5 6 7 8 9 A B C D E F ; do
for c in 0 1 2 3 4 5 6 7 8 9 A B C D E F ; do
for d in 0 1 2 3 4 5 6 7 8 9 A B C D E F ; do
...
owwrite /settings/alias/add/$a$b.$c$d$e$f$g$h$i$j$k$l$m$n
Name_$a$b.$c$d$e$f$g$h$i$j$k$l$m$n
...
done
done
done
done
Paul Alfille
On Fri, Apr 1, 2011 at 5:11 AM, Vincent Danjean <vdanjean.p...@free.fr> wrote:
> 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
>
> It means that people wanting to deal with aliases can look at
> /settings/alias/* and /aliases. People/software that wants plain info
> can look at the 'classical' tree.
>
> In any cases, it is very important to quickly specify which characters
> are allowed in aliases names. I recall that " " and "\n" for example are
> two valid characters in filename under POSIX. This is very important in order
> to design the format of /settings/alias/* (to list, add, remove, rename,
> ... aliases)
>
> Regards,
> Vincent
>
>> Paul Alfille
>
> --
> Vincent Danjean Adresse: Laboratoire d'Informatique de
> Grenoble
> Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot
> Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann
> Email: vincent.danj...@imag.fr 38330 Montbonnot Saint Martin
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
------------------------------------------------------------------------------
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
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
