Subject: Questions about the Require Command.

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 12 Dec 2000 15:58:22 -0000

2 Questions.

--------------------------------------------------------------------------------

  2.10.5 Extensions and Optional Features

  <snip>

  If an extension is not enabled with "require", implementations MUST
  treat it as if they did not support it at all.
By this do we mean that if a script uses a fileinto action, but didn't declare it with require, then we should produce an "unsupported extension" error when we reach the fileinto token even if we support fileinto?

i.e. take the following script.
  require "regex"

  if (header :regex "Cc" 
      "Some regular expression or other") {
      fileinto "FolderName";
  }
If we support both fileinto and regex are we meant to produce an error here?  I could see how you could interpret section 2.10.5 this way but surely if we are being conservative with what we produce, and liberal with what we receive we should accept this script and accept the fileinto command?

Could someone clear this up for me?  I'd suggest a re-wording of the section to make the intention clearer/more spelt out.

--------------------------------------------------------------------------------

  3.2 Control Structure Require

  <snip>
  The require command, if present, MUST be used before anything other
  than a require can be used. An error occurs if a require appears
  after a command other than require.

Could we improve the wording here too?  It took me quite a while to get my head round what you were getting at (even though I could have guessed).  I am assuming that this means that you may only have comments, whitespace and require commands before a require command.  It could read:

  Require commands, if present, MUST occur before all other types of command in the script.  An error occurs if a require appears after a command other than require.

So therefore this would be ok:

  /* This is the main require extension command that declares the extensions that we are about to use */
  require ["regex","fileinto"]

  # This is an auxilliary require command added by a user.
  require "x_some_other_extentsion"

  if (header :regex "Cc" 
      "Some regular expression or other") {
      fileinto "FolderName";
  }
but not
  require "regex"
  if (header :regex "Cc" 
      "Some regular expression or other") {
      keep;
      stop;
  }

  require "fileinto"

--------------------------------------------------------------------------------

Could I also just say that THE ONLY avenue though which this mail account is getting any junk mail at all, is through being on this mailing list.  Kinda ironic isn't it?

Cheers,

Nigel

---

From: [email-masked]
Date: Tue, 12 Dec 2000 13:15:53 -0700 (PDT)

> By this do we mean that if a script uses a fileinto action, but didn't
> declare it with require, then we should produce an "unsupported extension"
> error when we reach the fileinto token even if we support fileinto?

The important thing is that an error is produced. I don't think
it is critical that the specific error be "unsupported extension". After
all, we don't even have a precise error return model in this work.

> If we support both fileinto and regex are we meant to produce an error here? 

I believe you should produce an error in this case.

> I could see how you could interpret section 2.10.5 this way but surely if we
> are being conservative with what we produce, and liberal with what we receive
> we should accept this script and accept the fileinto command?

IMO this isn't a good place to apply this principle.

> Could someone clear this up for me?  I'd suggest a re-wording of the section
> to make the intention clearer/more spelt out.

I have to say I see nothing unclear here. If you don't have a require clause
for a particular extension it isn't legal to use it. Requiring an unrelated
extension doesn't change this.

> Could we improve the wording here too?  It took me quite a while to get my
> head round what you were getting at (even though I could have guessed).  I am
> assuming that this means that you may only have comments, whitespace and
> require commands before a require command.  It could read:

>   Require commands, if present, MUST occur before all other types of command
> in the script.  An error occurs if a require appears after a command other than
> require.

I have no problem with this.

>   require "fileinto"

Yes, exactly.

				Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 13 Dec 2000 14:11:58 -0000

<snip>

> extension doesn't change this.

Well I seem to have interpreted it correctly, so from that point of view I guess it is clear, but I just don't understand why we want to operate this way.  

Why should it only be legal to use an extension if it was previously declared with a require command?  What does this gain us?  I agree that it is naughty to use a command without "require"-ing it beforehand.  GUIs/users should make every effort to make sure this list is upto date.  But it seems a bit harsh to fail a script when it uses an extension that we know about, where it wasn't "require"d at the top of the script.

It certainly makes things more complicated in our Sieve engines as we need to have a list of available extensions that is added to by means of the require command.  Then whenever we find an extension we have to check its presence in our list.

Do we want the require command to "enable" extensions because a script should really be thought of as a whole, and if we can't do part of it then we shouldn't do any of it?  If this is the case then surely a just-in-time parser is a really bad idea, as it will pass some scripts that a full-parse-then-execute implementation will fail.

Do we want the require command to "enable" extensions because future extensions may have much further reaching structural consequences so if we don't understand the extension the can't guarantee that we can use any of the script correctly?  Again this is yet another reason why just-in-time parser are really going to be a rubbish solution.

But then a just-in-time parser solution is a great idea, dramatically saving on execution time on a busy server.

Is it because we want to force scripts to have upto date require lists?

I don't see how we can say that the require command "enables" the use of the extension for the current script, and that therefore the use on an extension without corresponding require command is an error, but then also say that it's alright to have a just-in-time implementation.  On a related point about section 2.10.6 I'd say that implementations SHOULD "go so far as to ensure that execution is atomic (either all actions are executed or none are executed).", not "might even".

I probably just need to hear the arguments.  If someone could explain then that would be great.  Something more than just an "IMO" please.

Cheers.

Nigel

---

From: [email-masked]
Date: Wed, 13 Dec 2000 08:16:38 -0700 (PDT)

> Well I seem to have interpreted it correctly, so from that point of view I
> guess it is clear, but I just don't understand why we want to operate this way.

Well, I wasn't a strong proponent of this scheme, so I'm probably not the one
to explain it. Nevertheless, it is my understanding that there was a strong
desire to be able to determine authoritatively the extensions a given script
uses based on a cursory examination of the initial part of the script.

One of the reasons why this is useful is because in general it may not be
possible to determine exactly what extensions a given script uses. For one
thing, the names of the commands or paramters or whatever involved in an
extension may not correlate with the extension name.  And in fact it is
possible that dependence on an extension isn't even derivable from an
inspection of the script content.

> It certainly makes things more complicated in our Sieve engines as we need to
> have a list of available extensions that is added to by means of the require
> command.  Then whenever we find an extension we have to check its presence in
> our list.

Well, once there's a consensus that such a list should be part of all scripts,
it is obvious that the only way to insure the presence of such a list in every
script is to make things fail when it isn't present. We have way too much
experience with optional declarative mechanisms to believe otherwise. And a
declarative scheme like this that is used only occasionally is worthless.

> Do we want the require command to "enable" extensions because a script should
> really be thought of as a whole, and if we can't do part of it then we
> shouldn't do any of it?  If this is the case then surely a just-in-time parser
> is a really bad idea, as it will pass some scripts that a
> full-parse-then-execute implementation will fail.

You're looking at it backwards. The use of require makes it possible to use
just-in-time schemes. Without it things get messy -- you have scripts that
succeed sometimes and fail other times, and that violates the least
astonishment principle big time.

> Do we want the require command to "enable" extensions because future
> extensions may have much further reaching structural consequences so if we
> don't understand the extension the can't guarantee that we can use any of the
> script correctly?  Again this is yet another reason why just-in-time parser are
> really going to be a rubbish solution.

Again, you're looking at it backwards.

> on execution time on a busy server.

Sure.

> Is it because we want to force scripts to have upto date require lists?

We want this too.

> I don't see how we can say that the require command "enables" the use of the
> extension for the current script, and that therefore the use on an extension
> without corresponding require command is an error, but then also say that it's
> alright to have a just-in-time implementation.  On a related point about
> section 2.10.6 I'd say that implementations SHOULD "go so far as to ensure that
> execution is atomic (either all actions are executed or none are executed).",
> not "might even".

Given that in many implementations some actions may be deferred or even
passed off to an entirely different agent to implement, I don't think this
is practical.

					Ned

---

From: "Nigel Swinson" <[email-masked]>
Date: Wed, 13 Dec 2000 16:47:56 -0000

So in essense we want to force wherever we can that the require list is up-to-date so that we can use just-in-time parsing.  The way we force all scripts to keep their require commands up-to-date is by using the require command as an "enable extension" mechanism, so if the user wants to use an extension they have to "require" it.

Those scripts that do not properly declare their extensions with the require command will possibly pass a just-in-time parse, but we should make every effort we can to ensure that this does not happen by warning the users in the gui or at run time.

Ok I think I get it now.

Thanks for your time.

Nigel