[alicebot-archcomm] [proposal] <get pattern=

Noel Bush alicebot-archcomm@list.alicebot.org
Sun, 4 Nov 2001 17:57:07 +0300


This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C1655A.1F71AC90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Let's try this again; there were a lot of "spurious" things there.

> -----Original Message-----
> From: alicebot-archcomm-admin@list.alicebot.org 
> [mailto:alicebot-archcomm-admin@list.alicebot.org] On Behalf 
> Of Noel Bush
> Sent: Sunday, November 04, 2001 5:56 PM
> To: alicebot-archcomm@list.alicebot.org
> Subject: RE: [alicebot-archcomm] [proposal] <get pattern=
> 
> 
> The text file had a spurious item ii attached to item i under 
> 2; ignore
> the spurious item ii.

------=_NextPart_000_0012_01C1655A.1F71AC90
Content-Type: text/plain;
	name="get-pattern-that-topic.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="get-pattern-that-topic.txt"

(View without word wrap.  The long lines are that way on purpose.)

0. Each input path is stored, with the most recent first.  One way might =
be:

<user> RICHARD WALLACE <matched> HELLO ALICE <that> * <topic> * <with> =
Hello, Alice! <that> CONNECT <topic> *
<user> RICHARD WALLACE <matched> * <that> WHAT ARE YOU DOING <topic> * =
<with> I am writing more targets. <that> WHAT ARE YOU DOING <topic> *

0a. Matches on identical paths overwrite one another.

1. Each time a <set> is performed, the new value is stored and =
associated with=20
the input path.  The previous values are retained.  Might look like:

<user> RICHARD WALLACE <predicate> doing <after> I am writing more =
targets. <was> writing more targets
<user> RICHARD WALLACE <predicate> doing <after> I'm eating lunch. <was> =
eating lunch

2. Each time a <get> with a pattern and/or that and/or topic attribute =
is=20
performed, the engine "reconstructs" the original situation, by going =
through=20
the following steps:

   i. The given path (from the pattern, that and topic attributes) is =
sought in=20
      the stored inputs. ii. The template associated with the path is =
retrieved.
   ii. The category associated with the path is retrieved.
   iii. Each time a <get> with a name attribute is encountered in the =
retrieved=20
        category's template, the engine steps backwards through the =
different values=20
        that may have been assigned to the predicate.  It does this by =
stepping=20
        backwards through inputs until it finds the first one that =
matches an input=20
        associated with the setting of a predicate value. iv. The value =
that the=20
        predicate had at the time the retrieved template was used, is =
used to=20
        re-process the template. iv. The value that the predicate had at =
the time the=20
        retrieved template was used, is used to re-process the template. =
iv. The=20
        value that the predicate had at the time the retrieved template =
was used
   iv. The value that the predicate had at the time the retrieved =
category was used
       is used to re-process the template.
   v.  Srais are handled no differently: the values captured by the =
wildcards in the
       category's pattern, that and topic will be the same because the =
entire path
       was retrieved.

3. It's true that <random> probably presents the funniest problem.  How =
to=20
retain the notion of reconstructing the response?

To me it is worth giving up the idea of retrieving the exact random =
response, in=20
order to retain this "reconstruction" notion.

I like the notion of reconstructing the response better than just =
storing the=20
response because it offers the change to *use* the contents of the =
template,=20
rather than just returning the whole thing.
------=_NextPart_000_0012_01C1655A.1F71AC90--