Hi Cyrus,
On Sunday 19 October 2003 21:37, Cyrus Daboo wrote:
<snip>
| 1. The managesieve draft needs to mention that it acts on the local
| script storage, not on the global one.
Actually it might be nice to allow access to the global script space.
That could be done by adopting the new syntax used in include, e.g.:
a PUTSCRIPT :global "aGlobalScript" {31+}
etc
There could be a new "INCLUDE" capability for ManageSIEVE to do that.
Whether that is part of the ManageSIEVE draft or the include draft or
a separate document is open for debate.
I don't think it's good to allow any user to access the global script
space. List it, yes, so the Sieve editor can present the global scripts
in the GUI to choose from, but adding new ones should be left to the
admin or another role. So if the person filling the role of global
script manager needs to access the global script store, then she can
just as well log in as that role.
| 2. It needs to be clarified that the active script is the "start
| script" and that included (local) scripts need not (and cannot) be
| set active to be executed.
Why would you prevent a script that can be used as an include from
being made active?
Sorry, I was not precise enough. Of course, if your scripts form the
following DAG:
A
+ B
+ C
+ D
where A is the active script, you can make any one of B, C, D active and
it becomes the start script, at which execution starts. What I wanted
to say is that only the start script needs and can be made active and
that B can then be included, even though it isn't set active. In short,
the active flag does not act like an exec permission.
| 3. Either the managesieve or the include spec need to clarify that
| scripts that other scripts depend on (e.g. "includees") may not be
| removed from the script store (return NO) and that includees have
| to be uploaded before their includers.
That kind of dependency is going to be a pain.
Then
include "non-existant-script.siv";
needs to be made legal and a noop. I've got no strong preferences either
way, and can see nice use cases for the include-if-exists behaviour,
but execution of a formerly valid script MUST not error out only b/c
one of the included scripts has been deleted meanwhile.
| 4. There needs to be a managesieve protocol extension to report
| more precise errors (machine-readable) for PUTSCRIPT: E.g. parse,
| syntax, site policy, and dependency errors, together with line and
| optionally column number. Actually, I think this should go into
| managesieve proper.
With includes it may actually be useful to have a 'CHECKSCRIPT'
command that verifies a script and produces verbose error comments.
That would be useful when constructing a set of scripts with includes
dependencies.
According to the current draft, PUTSCRIPT must (or should?) not accept
invalid scripts. So it needs to parse them for validity and probably
also perform some more sophisticated analysis on it (various nesting
depths, site policy violations, etc.) anyway. So you can just as well
tell the client about your findings. CHECKSCRIPTS duplicates
PUTSCRIPT-in-non-authenticated-state.
| 5. A method (read: managesieve extension) to specify more than one
| active script and the order in which those are to be processed
| would also be nice, although personally, I'd be fine with using
| driver scripts (which, however, requires the include extension).
That would be just the same as having one top level script that
includes all the 'active' scripts in the order you want - I don't see
why ManageSIEVE should allow that directly if include is supported in
SIEVE itself.
That's what I meant by driver script. ;-)
Marc
--
[...] the USA needs a German product: Vergangenheitsbewältigung
-- Craig Morris: US boycott of products from countries against war?
www.telepolis.de
pgpAlEkIKquTD.pgp
Description: signature