Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EEF8D58.1020906@apache.org>
Date: Tue, 17 Jun 2003 16:51:20 -0500
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.3.1) Gecko/20030425
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: [vote results] FOM
References: <bcg7h2$i1q$1@main.gmane.org>
 <004101c3341b$4ad3ed30$7100000a@WRPO>
In-Reply-To: <004101c3341b$4ad3ed30$7100000a@WRPO>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

The vote clearly indicates the community wants the "small -> big"
approach. Chris has also removed his concerns. This gives us green light
to go ahead and finish the FOM design as we proposed it.

on 6/16/03 10:23 AM Reinhard P�tz wrote:

> 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?

I see two different types of components in Cocoon today:

 1) general components (example: SaxParser)
 2) sitemap components (example: FOPSerializer)

I think the flow should have access only to the first family.

This leaves one important problem: for the way cocoon is currently
designed, it is not easy for a user to deploy a new general component
inside cocoon since it has to modify the role descriptor that ECM
(extended component manager) uses.

There could be many ways to solve this, but I think the design of "real
blocks"(tm) and the use of more modern component containers (such as
fortress, for example) will remove this problem.

Note that, from a strictly FOM point of view, how easy it is for the
user to deply now general components is not a concern.

Also note that it is not defined *HOW* the FOM will identify the
component to be loaded. Thanks to weak typing, we don't have to care
about this at this point.

So, for today, the FOM should be implemented that only general
components are loadable and they are identified thru their roles or
their short names (as listed in the role file)

>  - 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?

Ricardo and I discussed this extensively a night ago. My proposal would
be to add a call such as

 sendPageAndFinish()

that would remove all the continuations from the tree and free all
loaded components.

but there are still a bunch of issues with the use of stateful
components in a continuation-driven environment and I'm not sure we have
enough information just yet to understand what is the best way to handle
this.

So, it would be best to let the flow writer take care of everything and
provide a dispose() hook to the FOM, potentially deprecatable once we
idenfity how to do transparent component garbage collection in a
continuation-driven environment and stateful components that are not
aware of this.

Still, the mix between continuations-based state handling and other
forms of state handling (say, transparent EJB transactionality, for
example) will very likely become the single focus of future research in
this community.

>  - Should the flow _always_ be associated with a Session?

I haven't written a flowscript that didn't require, in some way or
another, the availability of some statefulness on data and it seems to
me as overkill to use full execution state preserving (and the
URI-encoding of the continuation every time!) just for the data
(besides, even today, if you want to keep global flow variables around,
you have to enable sessions anyway)

In general, it is true that continuations and sessions are different
beasts, but in real life, continuations *extend* sessions since they
provide the ability to save *even more* state than sessions.

But in those situations where procedular flow is weak and navigation
decisions are driven by user action and not by flow execution,
continuations are overkill and sessions are still the preferred way to go.

is there a real need for continuations without sessions? i really can't
provide a meaningful example of this.

so, I would say +1 to this.

if you are against this, please speak up now.

>  - 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 ...

Again, I'm in favor of removing this altogether, but I would like a vote
on this as well.

>  - 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

I would say:

--attributes--
getAttribute(name)
getAttributeNames()
setAttribute(name,value)
removeAttribute(name)

--parameters--
getInitParameter(name)

I see no need for the others methods to be explosed at the flow level.

> 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?

Uh, you're right. I overlooked that.

I really have mixed feelings about this. Currently, the WebContinuation
object is exposed to the FOM and used in system.js to implement
sendPageAndWait(). I don't like this because it exposes too much of the
continuation machinery internals to the flow layer.

So, at least, if the continuation object is left, the ability to
contruct a new continuation should not be exposed in the FOM.

But at the same time, why would we need direct access to the
continuation object? the only valid reason is to invalidate the
continuation, but again, it feels kinda anti-scripting to have to go
chasing the continuation and invalidate it.

does anybody have a real-life example of the need for having access to
the continuation object?

>  - Do we need access to the modules? 

what modules?

> Or is the prefered way using
>    getComponent( id ) in the future?
> 
> 
> Are there any other open points?

Vadim suggested that we make the session object available as a property
of the cocoon object instead thru the getSession() method and I agree
that this might be desirable and provide consistency.

Please, if we overlooked something, let us know so that we can finalize
the FOM design and start implementing it.

-- 
Stefano.