Well, it's been far too quiet here, so I thought I'd poke on a
peripheral put important matter - script storage. I haven't seen any
messages on how/where scripts would get stored. We at Netscape (nee
"The Alliance" but I'll pass on that for now) want to store Sieve
filters in user LDAP entries, but there's a consideration of note.
(Note: people uninterested in LDAP can probably tune out here, but might
want to look briefly at the 'Solution?' section below)
We figure that generally the U/I for Server Side Rules will be that
users select a filter type (e.g. spam rejection, vacation, folder
storage,...) create a rule of that type, and then organize the rules in
order desired to run. The problem is that this creates a fair amount of
'meta-information' about a filter script that needs to get stored, e.g.
filter type and order to run. I don't particularly want to store this
info with the script, but there's an annoying problem with LDAP -
there's no inherent way to order attribute values. That is, if there
are attributes scriptSource and scriptRunOrder, each with three values,
there's no guaranteed order of return, so no way to make sure that the
three values picked from one attribute matches with the other. e.g.:
given...
scriptSource: (script1)
scriptSource: (script2)
scriptSource: (script3)
scriptRunOrder: 1
scriptRunOrder: 2
scriptRunOrder: 3
There's no way to guarantee that script1 will match up with
scriptRunOrder of 1.
Solution?
I'd like to proclaim that every script stored in LDAP should have a
unique name. Furthermore, this name should be in the script source, and
can be used to tie it to other parameters. What I was thinking of was
having a 'special' comment line at the beginning of the script, e.g.:
# !Name=This is my script #1
(script)
Where the "!Name=" identifies the 'special' line. That can then be used
in other attributes to tie them to the appropriate script: e.g.
scriptRunOrder: 1 = This is my script #1
making sure that the scriptRunOrder of 1 gets associated with "This is
my script #1".
I realize that this isn't perfect, e.g. people who modify LDAP directly
could easily screw up the association by changing a name in just one of
the 'tied' attributes, or putting in a script with no name. But I think
it's a reasonable solution that makes minimal demands on script format.
I was thinking that it might be nice to standardize this, so that any
client can handle organizing multiple filters, in the spirit of trying
to make Sieve truly interoperational. Any thoughts? Indeed, any
thoughts on script storage in general?
Cheers,
Bruce