Subject: I-D ACTION:draft-daboo-sieve-include-04.txt (fwd)

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Jun 2006 22:34:45 -0400

------------ Forwarded Message -----------
Date: June 13, 2006 6:50:01 PM -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-daboo-sieve-include-04.txt

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

	Title		: SIEVE Email Filtering: Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-04.txt
	Pages		: 13
	Date		: 2006-6-13
	
---------- End Forwarded Message ----------

Hi folks,
The new version of the include draft now defines the interaction with the 
variables extension. There are now 'export' and 'import' commands that 
control access to variables across scripts. Comments welcome...

-- 
Cyrus Daboo

Subject: I-D ACTION:draft-daboo-sieve-include-04.txt
From: [email-masked]
To: [email-masked]
Date: Tue, 13 Jun 2006 18:50:01 -0400
List-Id: i-d-announce.ietf.org

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

	Title		: SIEVE Email Filtering: Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-04.txt
	Pages		: 13
	Date		: 2006-6-13
	
The SIEVE Email Filtering "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-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-include-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-include-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 26 Jun 2006 20:36:50 +0100

> Filename : draft-daboo-sieve-include-04.txt

Boring nit:

-   The explicit use of "export and "import", coupled with the default
+   The explicit use of "export" and "import", coupled with the default

Must you do this?

   In the examples below, script content is indicated by a '|' as the
   first non-space character on a line for clarity.  The '|' characters
   are not part of the script itself.

Means copy/paste of sieve code is awkward. :o(

In:

   The "import" command contains a string list argument that defines one
   or more variables names of variables exported and set by other
   scripts which should be made available to the current script.

and:

   If an "import" command lists a variable that has not been exported
   and set by any other script at that point during the SIEVE execution
   process, then an error MUST occur.

If you remove "and set" as agreed, then what is the difference between import and export?  I'm not clear why we can't just have a "global" command with a string list argument of variables instead.  Either that or just specify that all variable names starting with "global." have global scope.

Must we say this?

    The "import" command, if present, MUST be used immediately after any
   "require" commands (at least one of which will be present listing the
   "include" extension).  Multiple "import" commands are allowed.  An
   error occurs if an "import" command appears after a command other
   than "require" or "import".  Use of the "import" command makes the
   listed variables immediately available for use in the body of the
   script that uses it.

I would imagine a use of import would be linked to some kind of "rule".  If later we remove the rule, we may forget to remove the variable names from the "import" and then our "import" command will slowly fill up with silt.  I'd prefer to "declare" the variables near their use.  Is there some technical reason why we want it that way or are you trying to enforce a script writing prefence?  

This restriction in C is one of the reasons I tend to convert .c files to .cpp even if I have no immediate plan to use objects. :o(

Cheers

Nigel

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 26 Jun 2006 19:37:10 -0400

>    or more variables names of variables exported and set by other

[aside: too many "variables" there]

> If you remove "and set" as agreed, then what is the difference between
> import and export?  I'm not clear why we can't just have a "global"
> command with a string list argument of variables instead.  Either that
> or just specify that all variable names starting with "global." have
> global scope.

In preparing some comments (so far left on the floor), I had come up
with some twisted examples to illustrate questions about how import and
export interact, specifically contrasted with simple global variables.
The best I can make out is that import and export coordinate through
some sort of import/export namespace (as contrasted with global
namespace, which it really isn't):

   - import pre-initializes a variable's value from the same-named
     variable in the import/export namespace, requiring that at some
     other point in script execution, some code has set up that variable
     in the import/export namespace;
and
   - export says that whenever a script context changes (i.e. it
     'return's to its includer, or it 'include's another script), the
     exported variable's value is published into that of the same-named
     variable in the import/export pool.

If this is correct, then it just makes me wonder:  wouldn't it be just
as useful to make "import" and "export" be action commands, allowing a
script to push and pull variables out of the import/export namespace
without being subject to unintended side-effects (i.e. of not being able
to predict what, exactly, included scripts export into your nicely
imported variables)?  And that in turn makes me wonder, why not just use
a reserved namespace (like "include.")  and use "set" to do those
manipulations?  (Which is similar to what you said re 'global' only more
in line with what I read into what import/export is trying to do.)

> I would imagine a use of import would be linked to some kind of
> "rule".  If later we remove the rule, we may forget to remove the
> variable names from the "import" and then our "import" command will
> slowly fill up with silt.  I'd prefer to "declare" the variables near
> their use.  Is there some technical reason why we want it that way or
> are you trying to enforce a script writing prefence?
> 
> This restriction in C is one of the reasons I tend to convert .c files
> to .cpp even if I have no immediate plan to use objects. :o(

Yes, I think there's too much magic in import/export as currently
described.  In fact I'd prefer a whole nother approach to what 'include'
is trying to accomplish anyway, but that's for another potentially
inflammatory post :)

mm