> 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)
> 6. Aliases are shown by default, except if the /unaliased directory is
> requested
nice it's the network directory without alias, maybe wit some others directories
/unaliased
/unaliased/uncached ...
> 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.
let's get limits on FUSE docs ?
> 2. Writing to an alias field that doesn't exist requires too many
> changes in the path parsing code
maybe... if we have a symbolic link 'table' it could help a lot, but
it's a big change
symbolic link idea is more know instead 'alias' idea
> 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).
nice everythink in memory, no problem, all changes must be read before
owfs shutdown, maybe only more 1 write? at shutdown allowing backup of
alias?
> 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.
maybe a owserver/owxxx limit option? --max-alias=10
2011/4/1 Paul Alfille <paul.alfi...@gmail.com>:
> 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
>
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
------------------------------------------------------------------------------
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
