Return-Path: 
 <dev-return-1975-apmail-creadur-dev-archive=creadur.apache.org@creadur.apache.org>
X-Original-To: apmail-creadur-dev-archive@www.apache.org
Delivered-To: apmail-creadur-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 4BF8410BA1
	for <apmail-creadur-dev-archive@www.apache.org>;
 Tue,  9 Jul 2013 19:30:43 +0000 (UTC)
Received: (qmail 53195 invoked by uid 500); 9 Jul 2013 19:30:43 -0000
Delivered-To: apmail-creadur-dev-archive@creadur.apache.org
Received: (qmail 53169 invoked by uid 500); 9 Jul 2013 19:30:43 -0000
Mailing-List: contact dev-help@creadur.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@creadur.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@creadur.apache.org>
List-Post: <mailto:dev@creadur.apache.org>
List-Id: <dev.creadur.apache.org>
Reply-To: dev@creadur.apache.org
Delivered-To: mailing list dev@creadur.apache.org
Received: (qmail 53161 invoked by uid 99); 9 Jul 2013 19:30:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jul 2013 19:30:43 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of
 robertburrelldonkin@blueyonder.co.uk designates 80.0.253.70 as permitted
 sender)
Received: from [80.0.253.70] (HELO
 know-smtprelay-omc-6.server.virginmedia.net) (80.0.253.70)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jul 2013 19:30:37 +0000
Received: from [10.0.0.88] ([82.41.107.157])
	by know-smtprelay-6-imp with bizsmtp
	id yKWG1l00c3Pn3qi01KWGVB; Tue, 09 Jul 2013 20:30:16 +0100
X-Originating-IP: [82.41.107.157]
X-Spam: 0
X-Authority: v=2.0 cv=HK2bjfRv c=1 sm=1 a=88d0gGLtypzHIymzaNsW0A==:17
 a=p1AIxE7YGZkA:10 a=CQN4mW3yCHEA:10 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10
 a=a5Gf7U6LAAAA:8 a=Rv_QkpVCEVkA:10 a=g3HDBXd_cImxHOGcsiAA:9 a=wPNLvfGTeEIA:10
 a=yHIqe9kG5mgA:10 a=ayuXhTZxCkzSMjaF:21 a=P_ExHw8toG1tIui9:21
 a=88d0gGLtypzHIymzaNsW0A==:117
Message-ID: <51DC64C3.6070300@blueyonder.co.uk>
Date: Tue, 09 Jul 2013 20:30:11 +0100
From: Robert Burrell Donkin <robertburrelldonkin@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130702 Thunderbird/17.0.7
MIME-Version: 1.0
To: dev@creadur.apache.org
CC: sebb <sebbaz@gmail.com>
Subject: Re: [GSOC] Rat: Past, Present and Future
References: <51DB1725.4050301@blueyonder.co.uk>
 <CAOGo0VYT1m7vEjp+Zj4hi6h_GjJkHokyDpULaKRmzcwcJ-broQ@mail.gmail.com>
In-Reply-To: 
 <CAOGo0VYT1m7vEjp+Zj4hi6h_GjJkHokyDpULaKRmzcwcJ-broQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

On 07/08/13 21:41, sebb wrote:
> On 8 July 2013 20:46, Robert Burrell Donkin
> <robertburrelldonkin@blueyonder.co.uk> wrote:

<snip>

>> 2. analyse this model against policies, building a strongly-typed, immutable
>> report model
>
> Won't that require lots of memory?

Not sure about lots (the state required should be relatively small) but 
yes, more

> At present the source can be forgotten as soon as a match occurs.

Perhaps

An architecture where each document flowed through the system is likely 
to be more efficient and easier to parallelism.

However, I think that the current streaming design isn't particularly 
intuitive or obvious. I would be happy to retain an improved streaming 
design.

Robert