Subject: Draft for script 'include' capability

From: Cyrus Daboo <[email-masked]>
Date: Fri, 11 Apr 2003 12:22:38 -0400

Below are details for a new draft that I just posted that describes a 
script 'include' capability for including one script inside another. I 
suspect this will be somewhat controversial. Obviously this has relevance 
to the current discussion on variables, in particular with regard to 
scoping. All comments welcome...

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: SIEVE Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-00.txt
	Pages		: 8
	Date		: 2003-4-10
	
The SIEVE [SIEVE] 'include' extension permits users to include one
SIEVE script inside another.  This can make managing large scripts
or multiple sets of scripts much easier, as well as supporting
common 'libraries' of scripts.  Users are able to include their own
personal scripts or site-wide scripts provided by the local SIEVE
implementation.

A URL for this Internet-Draft is:
<http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-00.txt>

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 14 Apr 2003 05:20:27 +0200

[Cyrus Daboo]:
>
>   Below are details for a new draft that I just posted that
>   describes a script 'include' capability for including one script
>   inside another. I suspect this will be somewhat
>   controversial. Obviously this has relevance to the current
>   discussion on variables, in particular with regard to scoping. All
>   comments welcome...
>

thanks.  I think it looks good.  the only thing I don't like is
encoding private vs. global through the included filename.  (one of
the examples omits the directory prefix, btw.)

I prefer
  include :global "spam-tests";
over
  include "/global/spam-tests";

the default should be to look in the personal folder.

| 4 Open Issues:
|     
|     1   Should we allow URIs to point to scripts to include?

the possibility of reliance on external resources should not be
offered.

|     2   Should we allow string lists as argument to include?

I don't see the usefulness of it, but I don't care either way.

|     3   How should non-exist include scripts be handled?

error at compile-time or run-time depending on the implementation.

|     4   Interaction with variables?

global variables are visible.  numeric variables (match back
references) are kept across the include.  this enables the user to use
them for parameter passing if needed ...

    if string :matches "[email-masked]" "*" {
        include "am_i_rcpt";
    }

----

another issue is case-sensitivity for filenames.  this is glossed over
in fileinto as well, but I think it should be stated explicitly.
something like:

    The filename is case sensitive.  An implementation MAY refuse to
    allow two files whose names only differ in case.

actually, this should go into the Managesieve draft as well.

-- 
Kjetil T.

---

From: Rob Siemborski <[email-masked]>
Date: Mon, 14 Apr 2003 16:37:44 -0400 (EDT)

> the default should be to look in the personal folder.

I like this.

> the possibility of reliance on external resources should not be

I'm assuming your argument against this is "lack of utility" which I
suspect I can agree with.

> error at compile-time or run-time depending on the implementation.

I'd argue that these should be interpreted to be empty scripts, since I
suspect runtime errors could be more confusing to the end user.  (Since
generally users don't see explicit error notices from sieve runs).

The advantage of interpreting it as an empty script is you can have your
main script include stuff like "my-vacation-script" which then can just be
deleted when you come back, as opposed to having to modify your main
script.

I guess the issue is what does the user expect to happen, and I don't
really like causing one script to start failing just because an included
script dissapears.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y?
------END GEEK CODE BLOCK-----

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 14 Apr 2003 22:52:49 +0200

[Rob Siemborski]:
>   I'm assuming your argument against this is "lack of utility"

not really.  if scripts can be fetched by HTTP, you introduce a
reliance on a working name service both locally and at the remote
site.  you also need to punch huge holes in your firewall.
furthermore, the script must be downloaded for each invocation of the
include statement, which puts an additional strain on the server, and
slows down throughput (== more deliveries running simultaneously).

>   which I suspect I can agree with.

well, I don't see the great utility, either :-)

>   I'd argue that these should be interpreted to be empty scripts,
>   since I suspect runtime errors could be more confusing to the end
>   user.  (Since generally users don't see explicit error notices
>   from sieve runs).
>   
>   The advantage of interpreting it as an empty script is you can
>   have your main script include stuff like "my-vacation-script"
>   which then can just be deleted when you come back, as opposed to
>   having to modify your main script.

heh.  I'd prefer to keep my vacation-script around, and just disable
it from the main script.  I see your point, though.

>   I guess the issue is what does the user expect to happen, and I
>   don't really like causing one script to start failing just because
>   an included script dissapears.

how about typos?  those will be hard to find.

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Apr 2003 17:03:52 -0400

Hi Rob,

--On Monday, April 14, 2003 4:37 PM -0400 Rob Siemborski 
<[email-masked]> wrote:

|> I prefer
|>   include :global "spam-tests";
|> over
|>   include "/global/spam-tests";
|>
|> the default should be to look in the personal folder.
|
| I like this.

Seems OK to me too, and provides a little better extensibility -- see next 
comment.

|> | 4 Open Issues:
|> |
|> |     1   Should we allow URIs to point to scripts to include?
|>
|> the possibility of reliance on external resources should not be
|> offered.
|
| I'm assuming your argument against this is "lack of utility" which I
| suspect I can agree with.

I think we can skip this for now and if it ever becomes necessary we can 
simply define it as a new extension and use the 'include :uri "..."' syntax 
for it.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Apr 2003 23:30:59 -0600

>From my own experience: I came across a C compiler that was treating missing
include files as empty. I was very surprised as a user. So, I am in favor of
being explicit and fail interpretation/compilation when a file doesn't
exist.

Cheers,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel
IETF standard
related pages: http://orthanc.ab.ca/mel/devel/Links.html

I speak for myself only, not for my employer.
__________________________________________

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 15 Apr 2003 13:36:51 -0400

Hi Alexey,

--On Monday, April 14, 2003 11:30 PM -0600 Alexey Melnikov 
<[email-masked]> wrote:

|> From my own experience: I came across a C compiler that was treating
|> missing
| include files as empty. I was very surprised as a user. So, I am in favor
| of being explicit and fail interpretation/compilation when a file doesn't
| exist.

Alternatively, we could allow a ':nofail' parameter to include so that a 
user could explicitly turn on silent failures for missing include files. 
Thus if a user really wanted to do something along the lines of what Rob 
proposed, they could do that, e.g.:

include :nofail "my_optional_vacation_script";

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Tue, 15 Apr 2003 13:41:03 -0400

> being explicit and fail interpretation/compilation when a file doesn't

This is my feeling as well.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Apr 2003 12:02:18 -0600

> include :nofail "my_optional_vacation_script";

I don't think you should be that flexible. Just pick one way.

Alexey