Include 04 export/import

Aaron Stone <aaron@serendipity.cx> Wed, 14 June 2006 16:28 UTC

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5EGS4Fb021960; Wed, 14 Jun 2006 09:28:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k5EGS4aU021959; Wed, 14 Jun 2006 09:28:04 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mail.serendipity.cx (IDENT:p91e82qhdtz3zp78aq28@serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5EGS35S021953 for <ietf-mta-filters@imc.org>; Wed, 14 Jun 2006 09:28:03 -0700 (MST) (envelope-from aaron@serendipity.cx)
Received: from [192.168.0.14] (dsl3-63-249-106-4.cruzio.com [63.249.106.4]) by mail.serendipity.cx (Postfix) with ESMTP id EEFD06016D1D; Wed, 14 Jun 2006 09:28:02 -0700 (PDT)
Subject: Include 04 export/import
From: Aaron Stone <aaron@serendipity.cx>
To: cyrus@daboo.name
Cc: ietf-mta-filters <ietf-mta-filters@imc.org>
Content-Type: text/plain
Date: Wed, 14 Jun 2006 09:28:30 -0700
Message-Id: <1150302510.17583.122.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.2
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>

Hi Cyrus,

I remember the hangup for the include draft! It was the interaction with
variables ;-) Glad you've addressed it; I like the export/import idea.

Nits: there are two spelling errors in section 3.4.2, "intially" should
be "initially" and further down, "and error..." should be "an error".

Meat: has there been discussion on the list about what happens if an
undefined variable is used? I think it would be good to fall back on any
such definitions.

An included script could pull in more variables than were exported, and
simply find that some of them are not defined. For example, a :global
script might have some documented functionality like, "export ${this}
for some useful behavior, and ${that} for some other useful stuff." A
user might only set ${that}, but the script has imported both ${this}
and ${that}. I don't think it should cause an error.

On the other hand, it establishes a very strong contract with the
including-script, which must export all imported variables. Hmm.

Aaron