Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <reinhard_poetz@gmx.net>
To: <cocoon-dev@xml.apache.org>
Subject: Finishing  FOM
Date: Mon, 16 Jun 2003 17:23:51 +0200
Message-ID: <004101c3341b$4ad3ed30$7100000a@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <bcg7h2$i1q$1@main.gmane.org>
Importance: Normal

> From: Stefano Mazzocchi

<skip/>

> Chris suggests we release 2.1 without bothering the FOM because it 
> will need time to adjust anyway. I agree, but what really worries me 
> is the fact that we *already* know it's going to change radically and 
> releasing such a bad contract is not going to be good publicity for 
> cocoon in general from contract solidity perspective.
> 
> you can mark it as beta as much as you like, but people are going to 
> discover it, fall in love with it, use it for testing, then pressured 
> by their bosses, put it in production, then ask support for it, or at 
> least a back compatibility layer.
> 
> Do you really want to force our users to go thru this? I don't.

 
That's exactly the point! The flow needs users that implement it in many
real life projects to make it stable from an implementation point of
view (altough I think it _is_ already very stable.). But this needs a
stable interface (FOM) because otherwise many users will hesitate to use
it in production and I learned in the past that only real life problems
can really challange a new concept or technology.

And additionally I'm +1 for the evolutionary approach small to big
because it makes it easier to maintain your application in the future.

                                       - o -

So let's try to finish the FOM! 

First I summarized the agreed points here:

  [http://wiki.cocoondev.org/Wiki.jsp?page=FOM]


And after looking through the latest discussion of the FOM the open
points are:

 - Component loading 
   
   Object getComponent(id) -> obtains the component indicated by the
given ID
   
   Here
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105405317918849&w=2] 
   Stefano wrote:  "Obviously, the flow will not have access to *all*
components, 
   but only to components that will be 'flow-available'."

   Stefano, could you elaborate on this? 
   How would you make a component flow-available? How does this avoid
the
   possible abuse of the control flow?


 - stateful components -> how to release them?

   There have been two mails:
   RR:
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105464984417883&w=2]
   SW:
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105472379523896&w=2]

   Are there any more thoughts about this?


 - Should the flow _always_ be associated with a Session?


 - void callAction(name,map) -> invoques the action indicated by the
given name 
                                and pass the given map as model

   Is there anybody against removing it? Is there a real need for it?
   
   I would say we should remove it and point people asking for
   it to
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105407572313285&w=2]. 
   And if we want we can decide to add it to the FOM at every time ...


 - Context
   Which methods are available? Especially do we need setAttribute(
name, value )?

   see:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105405579422169&w=2


And here some points that have not been discussed yet (or overlooked by
me):

 - What has happened with the continuation object? Don't we need it any
more?

 - Do we need access to the modules? Or is the prefered way using
   getComponent( id ) in the future?


Are there any other open points?


Reinhard
PS: My time is very limited at the moment but I'm willing to help as
much as (and if) I can!