Mailing-List: contact lenya-dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lenya Developers List" <lenya-dev@cocoon.apache.org>
Message-ID: <3EDF1BAB.2060809@nada.kth.se>
Date: Thu, 05 Jun 2003 12:30:03 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.0.1) Gecko/20020823 Netscape/7.0
MIME-Version: 1.0
To: Lenya Developers List <lenya-dev@cocoon.apache.org>
Subject: Re: Workflow definition document
References: <bbhtsh$6mu$1@main.gmane.org> <3EDCB25B.3010300@nada.kth.se>
 <bbiddk$imu$1@main.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Andreas

Andreas Hartmann wrote:

...

> We decided to restrict the functionality of our interfaces to the 
> minimum that is needed for Lenya. 

Seem very reasonable.

> My intention was to create a very simple API and a basic implementation
> that can be replaced by an adapter for an existing engine. I kept the
> CMS stuff out of the workflow API for SoC reasons.
>
> I can spend very little time on implementing a flexible or more
> comprehensive solution, 

I did not meant that Lenya should contain something that is more 
flexible than your a) proposal. Rather that I believe that your a) 
proposal would be usefull as is, in other domains.

> but I might be interested in integrating
> an existing engine if this makes Lenya more stable or standards
> compliant. 

Even if I'm in general is very much for standard compliance, I have not 
been that entusiastic about the WF standards I have seen this far. At 
this stage I think that it is better to do something rather minimal.


...

>>> --------------------
>>> a) general + fexible
>>> -------------------- 
>>
>>
>> I would prefer this solution. As far as I can see, there is nothing 
>> in the basic state and transition model, or the workflow interfaces 
>> in the CVS that are specific for publishing. And as mentioned above 
>> there are so many use cases for WF outside publishing that it IMO 
>> would be a good idea to keep the WF engine rather flexible.
>
>
> Actually, I also prefer this one. But my intention is not the
> application outside of Lenya, but the implementation of
> publication-specific conditions and actions. 

Yes, it is probably hard to know beforhand about all kinds of 
publication-specific conditions and actions that could be needed, so a) 
is probably a much better even whithout taking use cases outside 
publishing into account.

>
>
> If you really think that the API can be used for other purposes,
> feel free to use it! But I'm afraid the current community won't
> invest much work in making it more flexible than we need for Lenya.
> Of course, if you want to do so - that would be great!
> The more applications there will be, the more consolidated
> code will develop (at least I hope so ...) 

For the moment I would be happy with Lenyas WF engine, but as always, 
the devil is in the details ;) there might been things that I have 
missed, we will see.

>
>> It would also be rather easy to build such a more flexible WF engine 
>> as there allready is a framework in Cocoon for building language 
>> interpreters. Take a look at the package 
>> org.apache.cocoon.components.treeprocessor. Sylvain Wallez wrote the 
>> treeprocessor a few years ago as he wanted to have a sitemap 
>> interpreter instead of a compiler. Back then there were also 
>> discussion about building a XML based flow handeling language within 
>> Cocoon, so he wrote a framework that was suposed to be general enough 
>> for building general XML configured interpreters that are based on 
>> Avalon components.
>
>
> Thanks for the info! I will take a look at the TreeProcessor. 

I took a closer look at the TreeProcessor and found out that I prommised 
a litle bit to much. Although large part of the framework is rather 
general there are a few dependencies on sitemap specific things at some 
central positions in the interfaces. This makes it hard to reuse it. 
Still I believe that much of the ideas in it would be good to reuse for 
a WF engine.

>
>> If you are interested in using the treeprocessor for implementing the 
>> WF engine, and more generaly in "Avlonizing" the WF components I 
>> would be happy to contribute.
>
>
> At least the latter one would be very interesting. I already thought
> about "Avalonizing" :) the engine.

I would be interested in taking part of that process and has earlier 
experience in building Avalon based frameworks. I will be traveling for 
the next two weeks, but after that I could spend some time on it.

>
>> Going more into the details in your proposal I think that the main 
>> ideas look good. I also think that it could be a good idea to take a 
>> close look at the sitemap and try to follow the conventions from it.
>
>
> > It will
> > be much easier to learn Lenya and other Cocoon based framework
> > if there is some common style for all configuration files.
>
> In fact, I already had this idea :)
> The basic structure (declaration of components, usage of components)
> is very similar. I decided against this to keep the files simple,
> but maybe it's really worth a thought to make it similar to sitemaps.
> Is this a general pattern that appears also in other document
> definitions? 

There are some style similarities to the sitemap in logkit.xconf and and 
instrumentation.xconf and to somewhat lesser degree in cocoon.xconf. But 
I don't recall any discussions about it on Cocoon-dev. Stefano sometimes 
refer to long discussions about sitemap design when Cocoon2 was created, 
I have no specific references.

> Let's see what the others think.
>
>> I also wonder about how you are integrating the WF engine with the 
>> sitemaps, I looked in the mail archives and browsed the code and 
>> couldn't find anything. Could you please give a link or some 
>> description of it.
>
>
> We probably won't integrate the WF with the sitemaps directly.
> I don't know if you're familiar with the Lenya task concept,
> this will be the main link between WF and CMS functionality.

Will that mean that the task basically is responsible for sending an 
event to a WF instance, and that there is a task for creating a new WF 
instance? In a later stage I think it would be a good idea to be able to 
controll the WF engine from flowscripts as well, as flowscripts more and 
more are becomming the prefered way to handle side effects within the 
Cocoon comunity (this is of course not an uncontroversial statment ;) ).

There is also a need for using and presenting the state of an WF 
instance from the sitemap. I saw that you have started a thread about 
the format of the WF instance. Are you planning to make the WF instance 
description available from a generator or what is your idea? I also 
wonder what your ideas are about identification and persistance for WF 
instances.

A WF definition need an identifier as well, I guess that there can be 
several different WF within a CMS so there is a need to be able to refer 
to a specific WF.

>
>
> Andreas
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org