Re: More on FOM

[Christopher Oliver]

Upayavira wrote:

On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:

...

 

I suggested that components being heavyweight resource, allowing
them to cross continuation boundaries should be prohibited.
Automatic release doesn't seem a good solution to me, as it would
mean that script variables would hold released components, thus
leading to unpredictable behaviour (think about stateful pooled
components). So my opinion is to raise an error if there are some
unreleased components when a continuation is created. This will
allow users to quickly learn the safe practices related to
component management in flow scripts.
   

I tend to agree. 

...

 

Once again, I agree that explicit release is very unnatural. But
automagic release is good only if we can have some automagic restore.
For this we can have getComponent() actually return a proxy to the
real component, and have the proxy do a release/lookup when a
continuation is suspended/reactivated. But as elegant this may seem,
this won't work : stateful components have... a state, and a
release/lookup cycle destroys this state.
So I don't see any other solution...
   

How about defining a FlowSafe interface (contains no state and can be 
released/looked up transparently), and maybe a FlowSerializable interface (has a way 
that the state can be stored into the continuation and then restored, all transparently?

 

Continuations do not serialize state. Continuations restore the program 
counter and cause you to retain references to function invocations and 
local variables, however they do not "roll back" the values of those 
variables.

Re: More on FOM

[Sylvain Wallez]

Upayavira wrote:

On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:

 



Once again, I agree that explicit release is very unnatural. But
automagic release is good only if we can have some automagic restore.
For this we can have getComponent() actually return a proxy to the
real component, and have the proxy do a release/lookup when a
continuation is suspended/reactivated. But as elegant this may seem,
this won't work : stateful components have... a state, and a
release/lookup cycle destroys this state.
So I don't see any other solution...
   

How about defining a FlowSafe interface (contains no state and can be released/looked up transparently),

We already have this with the ThreadSafe marker interface. So yes, we 
could have transparent release/lookup for ThreadSafe components.

and maybe a FlowSerializable interface (has a way that the state can be stored into the continuation and then restored, all transparently?

Good point. But actually, this is not related exclusively to flow, but 
to the ability to externalize the component state. So this could be :
interface StateExternalizable {
 Object /* or Serializable? */ getState();
 void setState(Object state);
}

So you would have to consciously code your components to use either of these interfaces, otherwise you'll have to manually release them before creating a continuation.

Yep. An you would still get an error if there are some unreleased 
components that are neither ThreadSafe nor StateExternalizable.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: More on FOM

[Christian Haul]

On 30.Jun.2003 -- 10:29 PM, Sylvain Wallez wrote:
> Ricardo Rocha wrote:
> 
> >Sylvain Wallez wrote:
> >
> >>Ricardo Rocha wrote:
> >>
> >Imo, the flow renders actions (and modules outside the sitemap) 
> >unnecessary, so we shouldn't encourage their continued use by 
> >providing FOM-level support for them. The idea, in the long term, is 
> >to stop using actions (and xsp's, for that matter) in favor of the flow.
> >
> >That said, *indirect* access to modules and actions would satisfy 
> >short-term, transitional requests to allow reuse of such "legacy" 
> >components from the flow (if only by popular demand :-)). 
> 
> Ok. So we allow some abuse to satify transition of legacy applications 
> or code.

I'm happy with the suggested legacy.js in conjunction with the changes
needed with regard to the object model.

Nag : I still believe that creating a new, cut-down request, session,
properties, cookie object for flow is unwise and we'd be better off
ripping them out and go through modules instead.  That would simplify
the FOM a lot and yet would be more powerful.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: More on FOM

[Upayavira]

On 30 Jun 2003 at 22:29, Sylvain Wallez wrote:

...

> >> I suggested that components being heavyweight resource, allowing
> >> them to cross continuation boundaries should be prohibited.
> >> Automatic release doesn't seem a good solution to me, as it would
> >> mean that script variables would hold released components, thus
> >> leading to unpredictable behaviour (think about stateful pooled
> >> components). So my opinion is to raise an error if there are some
> >> unreleased components when a continuation is created. This will
> >> allow users to quickly learn the safe practices related to
> >> component management in flow scripts.

I tend to agree. 

...

> Once again, I agree that explicit release is very unnatural. But
> automagic release is good only if we can have some automagic restore.
> For this we can have getComponent() actually return a proxy to the
> real component, and have the proxy do a release/lookup when a
> continuation is suspended/reactivated. But as elegant this may seem,
> this won't work : stateful components have... a state, and a
> release/lookup cycle destroys this state.
> 
> So I don't see any other solution...

How about defining a FlowSafe interface (contains no state and can be 
released/looked up transparently), and maybe a FlowSerializable interface (has a way 
that the state can be stored into the continuation and then restored, all 
transparently?

So you would have to consciously code your components to use either of these 
interfaces, otherwise you'll have to manually release them before creating a 
continuation.

Upayavira

Re: More on FOM

[Sylvain Wallez]

Ricardo Rocha wrote:

Sylvain Wallez wrote:

Ricardo Rocha wrote:

The following items reflect the discussions Stefano and I have had 
around the FOM:

- The load(uri) global function should be supported. This is clearly 
needed for nested source file inclusion (which  does not 
support).

- The cocoon.releaseComponent(component) method should be supported 
in conjunction with cocoon.getComponent(id). Further discussion is 
needed about whether the FOM implementation should automatically 
take care of releasing components.


Hehe, I should go to Ecuador, as I advocated both ;-)


You're welcome anytime my friend! :-)


Cool ! This is one of the good things of Apache : world-wide friends, 
ready to welcome you for good time and geek talks :-)

I suggested that components being heavyweight resource, allowing them 
to cross continuation boundaries should be prohibited. Automatic 
release doesn't seem a good solution to me, as it would mean that 
script variables would hold released components, thus leading to 
unpredictable behaviour (think about stateful pooled components). So 
my opinion is to raise an error if there are some unreleased 
components when a continuation is created. This will allow users to 
quickly learn the safe practices related to component management in 
flow scripts.


I see your point Sylvain. Your solution sounds somewhat draconian but 
it's probably the only safe bet...

The question then becomes: does anyone envision real-world scenarios 
in which stateful components *are* needed across continuation boundaries?
(if so, imo, it might imply curent Avalon component management isn't 
safe for continuations)

Or can we *always* formulate our flow so that we don't need to keep 
component state across continuations? (for example, database 
connections can be acquired/released as needed precisely because 
they're pooled). 


Databases connections are a good use case. IMO, the sequential nature of 
a flow script will make people want to keep stateful components as the 
do in "standard code", as it is somewhat unnatural to release a 
connection just before a sendPageAndWait() and then look it up just after.

The modified Rhino intepreter has some extensions to exception 
management to allow clearing and restoring variables when a continuation 
is suspended/reactivated. This will be very useful in large scripts when 
a continuation is suspended several function call deeper than the 
location where the component is used.

On a separate thread, if *all* acquired components *must* be released 
prior to creating a continuation... wouldn't it make sense for the FOM 
implementation to automagically release them??

I know it may sound dangerous at first, but then again it would 
relieve developers from that tedious, anti-scripting release idiom...


Once again, I agree that explicit release is very unnatural. But 
automagic release is good only if we can have some automagic restore. 
For this we can have getComponent() actually return a proxy to the real 
component, and have the proxy do a release/lookup when a continuation is 
suspended/reactivated. But as elegant this may seem, this won't work : 
stateful components have... a state, and a release/lookup cycle destroys 
this state.

So I don't see any other solution...

- There should be unrestricted access to all components via 
cocoon.getComponent(id).


Hehe again ;-)


Hahaha! There's nothing quite like the flavor of victory, is there? ;-) 


Mmmh... it's not about victory in the "fight" meaning, where there's a 
winner and a looser. We all win in discussing our thoughts and taking 
good ideas where they come. This time these are mine and, well, this 
feels good ;-)

Among other goodies, this will give indirect access to Actions and 
Modules without providing explicit FOM support for them. Access to 
request input modules, in particular, should account for 
request.getURI(). 


Two remarks here :
- if we give access to request.getURI through an input module, then 
why removing it from the request object ??


Until proven otherwise, I don't think getURI() is _needed_ by the 
flow, so the request object shouldn't expose it.


Actually, I think that if the flow needs something from the URI, this 
information should be passed by the sitemap through  in 
the . The sitemap is responsible for handling the URI space, 
including extracting information from it for other components.

Imo, the flow renders actions (and modules outside the sitemap) 
unnecessary, so we shouldn't encourage their continued use by 
providing FOM-level support for them. The idea, in the long term, is 
to stop using actions (and xsp's, for that matter) in favor of the flow.

That said, *indirect* access to modules and actions would satisfy 
short-term, transitional requests to allow reuse of such "legacy" 
components from the flow (if only by popular demand :-)). 


Ok. So we allow some abuse to satify transition of legacy applications 
or code.

- modules need the object model and

Re: More on FOM

[Ricardo Rocha]

Sylvain Wallez wrote:
Ricardo Rocha wrote:
The following items reflect the discussions Stefano and I have had 
around the FOM:

- The load(uri) global function should be supported. This is clearly 
needed for nested source file inclusion (which  does not 
support).

- The cocoon.releaseComponent(component) method should be supported in 
conjunction with cocoon.getComponent(id). Further discussion is needed 
about whether the FOM implementation should automatically take care of 
releasing components.
Hehe, I should go to Ecuador, as I advocated both ;-)
You're welcome anytime my friend! :-)

I suggested that components being heavyweight resource, allowing them to 
cross continuation boundaries should be prohibited. Automatic release 
doesn't seem a good solution to me, as it would mean that script 
variables would hold released components, thus leading to unpredictable 
behaviour (think about stateful pooled components). So my opinion is to 
raise an error if there are some unreleased components when a 
continuation is created. This will allow users to quickly learn the safe 
practices related to component management in flow scripts.
I see your point Sylvain. Your solution sounds somewhat draconian but
it's probably the only safe bet...
The question then becomes: does anyone envision real-world scenarios in 
which stateful components *are* needed across continuation boundaries?
(if so, imo, it might imply curent Avalon component management isn't
safe for continuations)

Or can we *always* formulate our flow so that we don't need to keep
component state across continuations? (for example, database connections
can be acquired/released as needed precisely because they're pooled).
On a separate thread, if *all* acquired components *must* be released
prior to creating a continuation... wouldn't it make sense for the FOM
implementation to automagically release them??
I know it may sound dangerous at first, but then again it would relieve
developers from that tedious, anti-scripting release idiom...
- There should be unrestricted access to all components via 
cocoon.getComponent(id).
Hehe again ;-)
Hahaha! There's nothing quite like the flavor of victory, is there? ;-)

Among other goodies, this will give indirect access to Actions and 
Modules without providing explicit FOM support for them. Access to 
request input modules, in particular, should account for 
request.getURI(). 
Two remarks here :
- if we give access to request.getURI through an input module, then why 
removing it from the request object ??
Until proven otherwise, I don't think getURI() is _needed_ by the flow, 
so the request object shouldn't expose it.

Imo, the flow renders actions (and modules outside the sitemap)
unnecessary, so we shouldn't encourage their continued use by providing
FOM-level support for them. The idea, in the long term, is to stop using
actions (and xsp's, for that matter) in favor of the flow.
That said, *indirect* access to modules and actions would satisfy
short-term, transitional requests to allow reuse of such "legacy"
components from the flow (if only by popular demand :-)).
- modules need the object model and actions need it also, along with a 
(Cocoon) resolver and a redirector. How will the flow be able to access 
these objects to pass them to the components ?
Yes, you're right. Reinhard also pointed this out.

IMO, the second point calls for some refactored interfaces since the 
(Excalibur) resolver is now a regular component and we decided some time 
ago to make the object model accessible through the Avalon context 
(don't know if it has been implemented, though).
Yes, this solution is clean. If the object model is available "legacy"
actions would be accessible.
What I'd oppose -in any case- is giving actions/modules first-class
status in the FOM...
Ricardo

Re: More on FOM

[Ricardo Rocha]

Reinhard Pötz wrote:

- There should be unrestricted access to all components via
cocoon.getComponent(id). 
I'll implement getComponent( id ) and releaseComponent( component) ASAP
because the current flow implementation exposes the component manager
and this leads to a serious bug! If you have more than one user the
component manager can become null. This can be very annoying if you want
to train some people ...
Cool :-)

Among other goodies, this will give indirect access to Actions and Modules
>> without providing explicit FOM support for them. Access to request
>> input modules, in particular, should account for request.getURI().
AFAIK many of them need the object model and this is not provided by the
flow so I think you have no chance to use the actions and input modules
which need objects of the object model. Am I right here?
Yes, you are... :-(

- Access to continuation objects should be provided.
	var kont = sendPageAndWait(uri, data)
This is deemed necessary as certain continuation usage
patterns may call 
for explicit, programmatic invalidation of continuations.
	- Properties
		- id
	- Methods
		- getParent()
		- getChildren()
		- invalidate()
	- Events
		- onExpiration()

sounds good. It should also be possible to create your own continuations
objects without sending a page. See the JXForms implementation which
needs this to provide previous/next-navigation.
Yes, creating continuations without sending pages is all-important.

I'll add all those things to the proposal ASAP.
Hey Reinhard, you're a committed committer, cool!

Regards,

Ricardo

Re: More on FOM

[Sylvain Wallez]

Ricardo Rocha wrote:

Hi friends,

The following items reflect the discussions Stefano and I have had 
around the FOM:

- The load(uri) global function should be supported. This is clearly 
needed for nested source file inclusion (which  does not 
support).

- The cocoon.releaseComponent(component) method should be supported in 
conjunction with cocoon.getComponent(id). Further discussion is needed 
about whether the FOM implementation should automatically take care of 
releasing components.


Hehe, I should go to Ecuador, as I advocated both ;-)

I suggested that components being heavyweight resource, allowing them to 
cross continuation boundaries should be prohibited. Automatic release 
doesn't seem a good solution to me, as it would mean that script 
variables would hold released components, thus leading to unpredictable 
behaviour (think about stateful pooled components). So my opinion is to 
raise an error if there are some unreleased components when a 
continuation is created. This will allow users to quickly learn the safe 
practices related to component management in flow scripts.

- There should be unrestricted access to all components via 
cocoon.getComponent(id).


Hehe again ;-)

Among other goodies, this will give indirect access to Actions and 
Modules without providing explicit FOM support for them. Access to 
request input modules, in particular, should account for 
request.getURI(). 


Two remarks here :
- if we give access to request.getURI through an input module, then why 
removing it from the request object ??

- modules need the object model and actions need it also, along with a 
(Cocoon) resolver and a redirector. How will the flow be able to access 
these objects to pass them to the components ?

IMO, the second point calls for some refactored interfaces since the 
(Excalibur) resolver is now a regular component and we decided some time 
ago to make the object model accessible through the Avalon context 
(don't know if it has been implemented, though).

- Access to continuation objects should be provided.
var kont = sendPageAndWait(uri, data)
This is deemed necessary as certain continuation usage patterns may 
call for explicit, programmatic invalidation of continuations.
- Properties
- id
- Methods
- getParent()
- getChildren()
- invalidate()
- Events
- onExpiration()


Sounds good.

What do you guys think? 


Read inline !
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

RE: More on FOM

[Reinhard Pötz]

Hi Ricardo,

> From: Ricardo Rocha [mailto:[EMAIL PROTECTED]
> Hi friends,
> 
> The following items reflect the discussions Stefano and I have had
> around the FOM:
> 
> - The load(uri) global function should be supported. This is clearly
> needed for nested source file inclusion (which  does not 
> support).

+1

> 
> - The cocoon.releaseComponent(component) method should be
> supported in 
> conjunction with cocoon.getComponent(id). Further discussion 
> is needed 
> about whether the FOM implementation should automatically 
> take care of 
> releasing components.

I'm with you that this part will need more investigation and use cases.
But for now I'm fine without some automatism. So +1 too.

> 
> - There should be unrestricted access to all components via
> cocoon.getComponent(id). 

I'll implement getComponent( id ) and releaseComponent( component) ASAP
because the current flow implementation exposes the component manager
and this leads to a serious bug! If you have more than one user the
component manager can become null. This can be very annoying if you want
to train some people ...

> Among other goodies, this will give indirect
> access to Actions and Modules without providing explicit FOM 
> support for 
> them. Access to request input modules, in particular, should 
> account for 
> request.getURI().

AFAIK many of them need the object model and this is not provided by the
flow so I think you have no chance to use the actions and input modules
which need objects of the object model. Am I right here?

> 
> - Access to continuation objects should be provided.
>   var kont = sendPageAndWait(uri, data)
> This is deemed necessary as certain continuation usage
> patterns may call 
> for explicit, programmatic invalidation of continuations.
>   - Properties
>   - id
>   - Methods
>   - getParent()
>   - getChildren()
>   - invalidate()
>   - Events
>   - onExpiration()
> 
> 
> What do you guys think?

sounds good. It should also be possible to create your own continuations
objects without sending a page. See the JXForms implementation which
needs this to provide previous/next-navigation.

I'll add all those things to the proposal ASAP.

Reinhard