Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Reply-To: <reinhard@apache.org>
From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <reinhard_poetz@gmx.net>
To: <dev@cocoon.apache.org>
Subject: RE: [Vote] Controller/Sitemap integration
Date: Thu, 17 Jul 2003 23:24:54 +0200
Message-ID: <000f01c34ca9$ddb02b40$1e01a8c0@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3F1710EA.7040809@outerthought.org>
Importance: Normal

> Coming back on the vote:
> the issue here is not really about renaming these classes, but 
> about introducing this FlowState abstraction layer.  Your remark 
> rightfully makes me see I was starting to overlook the subtle nuance.
> 
> all in all, I have the feeling this is not really part of the 
> public interface we want to nail down here and now ?
> (meaning that I believe the introduction of this layer could be 
> done whithout much effect on applications that just use an 
> certain flow implementation, of course the flowprocessor impl's 
> themselves would have some refactoring ahead)

I don't understand the current flow implementation from Ovidiu and
Chris  or Sylvain's and your proposal in all depth but whatever 
the future brings should only change implementations - the user
shouldn't even notice that something has changed.

> the same remark probably goes for the FlowEngine/Processor and 
> might explain our lesser natural connection to these issues on 
> the table?

Sorry, I don't understand what you mean with this last paragraph.

Reinhard