Re: [Flow] Preparing the vote - long!
On 23.Jun.2003 -- 05:30 PM, Stefano Mazzocchi wrote: > on 6/22/03 5:06 AM Christian Haul wrote: > > > Although I don't like to mention it, action are dual use and by removing > > special support and restricting access to non-sitemap components they > > are completely banned. > > Yes, that's the intention. > > > Yes, a sitemap component could refer to a regular > > component to do the job, but > > I understand your concerns, expecially since you place lots of efforts > in actions, but let me ask you a question: > > shouldn't those general actions be abstracted into general components > that contain business logic instead of using a sitemap-specific > behavioral contract? Don't get me wrong, I do see that 95% of all actions will be of no use from the flow. And I don't mind to add new entry points or even split them up, after all, there're only a few actions worth it. But I'm a little concerned that you say it's no problem, actions will stay, actions will be available from flow, just need to look them up as normal components. At the same time you want to require a split between two types of components and accidently rendering everything else you said invalid. > By imposing a constraint, there will be a need to refactor those actions > out and clean them up. > > If we have a callAction() method, people will lazily use that and that > business-logic orientation refactoring will never happen. So what? If someone is reluctant to use flow or just wants to experiment with it, it should be as easy as possible IMHO. Having a way to call your "legacy" actions makes it easy. If the person then starts liking flow, the person will switch. I believe in evolution here, therefore I believe that flow will actually profit and attract more users if they can smoothly start using it. I'm doing this for pure fun -- I have no investments to protect so I'll be happy either way. But I believe this course might cause more harm than to allow this little impurity would do. 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: [Flow] Preparing the vote - long!
On 24/06/2003 0:25 Stefano Mazzocchi wrote: (2-mail-pattern, let's hope it works) I was suggesting we remove it from the FOM as I see no reason to connect sitemap programmatic artifacts in the flow realm. Read the title, it starts with [flow], is the context clear enough? Yes. I'm very sorry to have read more than you typed. It was not out of paranoia, but because I _am_ genuinely concerned that Flow must become a integral part of the community hivemind in order to succeed, and pushing it while dropping something else might be detrimental to that effect. But I misread you, apparently, so never mind. The caveat was already there. The concern remains. Anyway, I think we got the point that you people there at OT have such a great and better way of doing stateful control using actions. What about stopping your "Stefano will kill actions under our feet" paranoia and throw some code in the scratchpad to show your point? maybe both sides can learn something in the process. As I carefully typed before reluctantly injecting my own little piece of concern into this discussion: Oh. Do please read this as a neutral observation, will you? I'm not into flames. If I'm wrong with my observation, just say so and I'll withdraw to my cave. ;-) Thanks, Stefano. Is this a Cultural Revolution thing or what? Could you please play the ball instead of the man? -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Flow] Preparing the vote - long!
on 6/22/03 5:06 AM Christian Haul wrote: > Stefano Mazzocchi wrote: > >>on 6/20/03 2:01 PM Christian Haul wrote: >> >>>Reinhard Pötz wrote: > > ** * Component loading * ** >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. >>> >>>Fine. Although I don't see the possible abuse here. >> >>Having access to sitemap components would allow the flow writer to >>assemble pipelines at runtime, which is the closest thing I to abuse of >>cocoon internals I can think of. > > > Oh I see -- but that would require some hard core hacking. True. > Someone who > is determined enough to do that will probably find another way even with > this restriction. True as well, but not having access to it will make it a little bit harder. > Although I don't like to mention it, action are dual use and by removing > special support and restricting access to non-sitemap components they > are completely banned. Yes, that's the intention. > Yes, a sitemap component could refer to a regular > component to do the job, but I understand your concerns, expecially since you place lots of efforts in actions, but let me ask you a question: shouldn't those general actions be abstracted into general components that contain business logic instead of using a sitemap-specific behavioral contract? By imposing a constraint, there will be a need to refactor those actions out and clean them up. If we have a callAction() method, people will lazily use that and that business-logic orientation refactoring will never happen. -- Stefano.
Re: [Flow] Preparing the vote - long!
on 6/22/03 3:07 AM Steven Noels wrote: > On 22/06/2003 8:56 Upayavira wrote: > > >>Just to clarify - Stefano was only suggesting removing input/output >>modules from FOM, not Cocoon or the sitemap (where they are >>appropriate). >> >>Do your comments still stand? > > > If that was what he was aiming at, I stand corrected. Although I must > admit that his remark seemed more broadly stated (to me). I was suggesting we remove it from the FOM as I see no reason to connect sitemap programmatic artifacts in the flow realm. Read the title, it starts with [flow], is the context clear enough? Anyway, I think we got the point that you people there at OT have such a great and better way of doing stateful control using actions. What about stopping your "Stefano will kill actions under our feet" paranoia and throw some code in the scratchpad to show your point? maybe both sides can learn something in the process. -- Stefano.
RE: [Flow] Preparing the vote - long!
> From: Steven Noels [mailto:[EMAIL PROTECTED] > On 22/06/2003 6:01 Stefano Mazzocchi wrote: > > > Both actions and input/output modules were created to > overcome sitemap > > programmability limitations. Flow doesn't have those limitations > > anymore so i don't see the reason to keep those artifacts here. > > > > What do others think about this? > > I think the current community and mindshare behind flow is still too > small to already start deprecating 'old-fashioned hacks' I think nothing will be depracated - not at the moment. The time will show if there is still need for 'old-fashioned hacks'. > which were and > still are being (ab)used a lot for the same reasons flow will be > (ab)used for. Also, the continuations thing appears to be only one > possible way to address the webapp dev paradigm. I don't > think you are > suggesting an active depreciation, but suggestions like the one above > seem rather tendencious and suggestive IMHO. > > OK, it is only a small quote lifted out of context, but it is a good > illustration of my worry that flow, being a very interesting > approach, > still is _only_just_one_ approach to attack the given problem > domain. As Yes, one of _many_ approaches. > much as I'm genuinely interested in continuation-based flow, I think > flow needs some more real-world usage (like Pier's case) before we > consider it being part of the core features of Cocoon (on the > same level > of 'streamlined XML processing' and 'the sitemap'). I read the above > statement as a suggestion into that direction. Ok. Then we should tell our users that Cocoon 2.1 offers a new way of writing web applications, use the time until Cocoon 2.2 (or whatever) will be released to use the flow in more real life use cases. And then if we still say "Wow, what a revolutionary approach of writing web apps!" we can resposition Cocoon in that sense that the control flow is an equal part to the sitemap. (Please note, this has nothing to do with technology itself but with marketing!) What do you think? > If I say 'core', I mean the kind of stuff which you _have_ to > use if you > want to use Cocoon, not the 'blocks vs core' discussion, or > 'it has an > impact on the sitemap grammar'. I'm pretty sure that you > don't want to > see flow added to Cocoon with people openly saying 'ok', but silently > thinking 'whatever, I'm going to stick to my way anyhow'. > > Oh. Do please read this as a neutral observation, will you? > I'm not into > flames. If I'm wrong with my observation, just say so and > I'll withdraw > to my cave. ;-) > > Cheers, > > Reinhard
Re: [Flow] Preparing the vote - long!
Stefano Mazzocchi wrote: on 6/20/03 2:01 PM Christian Haul wrote: Reinhard Pötz wrote: ** * FOM (Flow Object model)* ** Context object -- --parameters-- getInitParameter(name) If I interpret this correctly you would provide the web.xml parameters as properties. Another possibility would be the attributes. Stefano, what do you think? IMHO it would be nice to access values like init parameters in a uniform way. That is what the input modules are all about. Therefore I would prefer to drop this and make it available through a module instead. Even though this entails an additional component lookup. Input modules were created with the pressure of the intrinsic low programmability of the sitemap and shine in that context. With a clearly They were created to prevent a starting combinatorial explosion of sitemap components, really. For example, we have wildcard matchers and regexp matchers, for request parameters, request headers, session attributes makes 6 matchers. Add request attributes makes 8... but we could do with 2 matchers and 4 modules. defined FOM, are you sure that having yet another abstraction layer is going to help us? The benefit is uniformness and indirection. Uniformness because o) all sources of are treated equal be it init parameters, configuration files, request attributes, request parameters, session attributes, attributes from the portal framework, whatever. We could introduce new objects into the FOM when the general need arises and hack our way in the meantime or have it plugable and clean. o) all those sources use the same interface: getAttribute(), getAttributeValues(), getAttributeNames(), no matter if they are originally called "attribute", "parameter", "header", "element" o) other places use already the same interface: transformers. sitemap, XSP logicsheet (input), actions Indirection helps in two ways o) ideally one would not use the predefined module names like "request-attr" but create application specific ones. With a few key strokes a different source is used. For example, use a XML file for testing and use real headers for deployment. o) when the application grows, perhaps you would like to keep your data in a database instead of the session or in a remote object -- no need to change anything in your script code, just replace the module. In addition, to create a restricted version of the request object, it needs to be wrapped anyways. Why not use the existing wrappers? Stefano: what modules? I meant the input and output modules. I think there is information available in input modules (e.g. static global parameters) that could be useful within flows. Output modules could be useful too. But maybe Christian could come up with more detailed explanations. Well, I feared this :-| First off: There is absolutely no *need* to have those however, they provide _uniform_ access to a lot of stuff that is often needed and what more. So the trade off here is to have uniform access and encapsulation versus additional indirection. IMO we should remove direct access to those sources and require to go through modules. I would say the exact opposite and my reason is simple: we have one FOM, while input modules are pluggable. But reading a request parameter differs from reading a request attribute, or a request header, or an init parameter. just like we agreed to keep one sitemap semantics, I don't see why we should change course on the contract between the flow writer and the way to get input data. I don't understand the analogy here, could you explain how this is related? The access is not only uniform across the source but also throughout cocoon since the modules are available in many places. This is a valid point, even if I see the need of sitemap input modules being lowered a lot with the advent of flow, and your point with it. Even with flow I see more and more very nice and elegant uses of modules in the sitemap. Very recent example: Virtual hosting uses different skins depending on the host. Solution: Neat, isn't it. I really don't see the value of input modules if we have FOM and general avalon compoments, because, just like actions, if they contain useful logic, this can be factored out in a general avalon component and called by the flow. They are general avalon components. I would like to make it really easy to use them and not go through the lookup-cast-use-release-cycle including the exception handling. It's a little heavy in a script just to obtain a value or two :-) Both actions and input/output modules were created to overcome sitemap programmability limitations. Flow doesn't have those limitations anymore so i don't see the reason to keep those artifacts here. OTOH since cocoon is not restricted to be used as servlet, why
Re: [Flow] Preparing the vote - long!
Stefano Mazzocchi wrote: on 6/20/03 2:01 PM Christian Haul wrote: Reinhard Pötz wrote: ** * Component loading * ** 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. Fine. Although I don't see the possible abuse here. Having access to sitemap components would allow the flow writer to assemble pipelines at runtime, which is the closest thing I to abuse of cocoon internals I can think of. Oh I see -- but that would require some hard core hacking. Someone who is determined enough to do that will probably find another way even with this restriction. Although I don't like to mention it, action are dual use and by removing special support and restricting access to non-sitemap components they are completely banned. Yes, a sitemap component could refer to a regular component to do the job, but 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: [Flow] Preparing the vote - long!
On 22/06/2003 8:56 Upayavira wrote: Just to clarify - Stefano was only suggesting removing input/output modules from FOM, not Cocoon or the sitemap (where they are appropriate). Do your comments still stand? If that was what he was aiming at, I stand corrected. Although I must admit that his remark seemed more broadly stated (to me). -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Flow] Preparing the vote - long!
On 22 Jun 2003 at 8:56, Steven Noels wrote: > On 22/06/2003 6:01 Stefano Mazzocchi wrote: > > > Both actions and input/output modules were created to overcome > > sitemap programmability limitations. Flow doesn't have those > > limitations anymore so i don't see the reason to keep those > > artifacts here. > > > > What do others think about this? > > I think the current community and mindshare behind flow is still too > small to already start deprecating 'old-fashioned hacks' which were > and still are being (ab)used a lot for the same reasons flow will be > (ab)used for. Also, the continuations thing appears to be only one > possible way to address the webapp dev paradigm. I don't think you are > suggesting an active depreciation, but suggestions like the one above > seem rather tendencious and suggestive IMHO. > > OK, it is only a small quote lifted out of context, but it is a good > illustration of my worry that flow, being a very interesting approach, > still is _only_just_one_ approach to attack the given problem domain. > As much as I'm genuinely interested in continuation-based flow, I > think flow needs some more real-world usage (like Pier's case) before > we consider it being part of the core features of Cocoon (on the same > level of 'streamlined XML processing' and 'the sitemap'). I read the > above statement as a suggestion into that direction. > > If I say 'core', I mean the kind of stuff which you _have_ to use if > you want to use Cocoon, not the 'blocks vs core' discussion, or 'it > has an impact on the sitemap grammar'. I'm pretty sure that you don't > want to see flow added to Cocoon with people openly saying 'ok', but > silently thinking 'whatever, I'm going to stick to my way anyhow'. > > Oh. Do please read this as a neutral observation, will you? I'm not > into flames. If I'm wrong with my observation, just say so and I'll > withdraw to my cave. ;-) Just to clarify - Stefano was only suggesting removing input/output modules from FOM, not Cocoon or the sitemap (where they are appropriate). Do your comments still stand? Regards, Upayavira
Re: [Flow] Preparing the vote - long!
On 22/06/2003 6:01 Stefano Mazzocchi wrote: Both actions and input/output modules were created to overcome sitemap programmability limitations. Flow doesn't have those limitations anymore so i don't see the reason to keep those artifacts here. What do others think about this? I think the current community and mindshare behind flow is still too small to already start deprecating 'old-fashioned hacks' which were and still are being (ab)used a lot for the same reasons flow will be (ab)used for. Also, the continuations thing appears to be only one possible way to address the webapp dev paradigm. I don't think you are suggesting an active depreciation, but suggestions like the one above seem rather tendencious and suggestive IMHO. OK, it is only a small quote lifted out of context, but it is a good illustration of my worry that flow, being a very interesting approach, still is _only_just_one_ approach to attack the given problem domain. As much as I'm genuinely interested in continuation-based flow, I think flow needs some more real-world usage (like Pier's case) before we consider it being part of the core features of Cocoon (on the same level of 'streamlined XML processing' and 'the sitemap'). I read the above statement as a suggestion into that direction. If I say 'core', I mean the kind of stuff which you _have_ to use if you want to use Cocoon, not the 'blocks vs core' discussion, or 'it has an impact on the sitemap grammar'. I'm pretty sure that you don't want to see flow added to Cocoon with people openly saying 'ok', but silently thinking 'whatever, I'm going to stick to my way anyhow'. Oh. Do please read this as a neutral observation, will you? I'm not into flames. If I'm wrong with my observation, just say so and I'll withdraw to my cave. ;-) Cheers, -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Flow] Preparing the vote - long!
on 6/20/03 2:01 PM Christian Haul wrote: > Reinhard Pötz wrote: > > >>** >>* FOM (Flow Object model)* >>** > > >>Context object >>-- >> >> >>>--parameters-- >>>getInitParameter(name) >> >> >>If I interpret this correctly you would provide the web.xml >>parameters as properties. Another possibility would be the >>attributes. Stefano, what do you think? > > > IMHO it would be nice to access values like init parameters in a uniform > way. That is what the input modules are all about. Therefore I would > prefer to drop this and make it available through a module instead. Even > though this entails an additional component lookup. Input modules were created with the pressure of the intrinsic low programmability of the sitemap and shine in that context. With a clearly defined FOM, are you sure that having yet another abstraction layer is going to help us? [snip] >>** >>* Component loading * >>** >> >> >> >>>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. > > > Fine. Although I don't see the possible abuse here. Having access to sitemap components would allow the flow writer to assemble pipelines at runtime, which is the closest thing I to abuse of cocoon internals I can think of. > > >>** >>* statefull components - how to release them?* >>** > > >>Sylvain: > > >>>1/ raise an error if there are some unreleased stateful components > > > Until we fully understand this I would go with the above. > > > >>** >>* Flow and sessions * >>** > > >>Note to the vote: >>+ >>So I think we could vote on the current implementation or can anybody >>come up with a use case that is not covered with the current >>implementation? > > > Fine. > > >>** >>* Map callAction(name,map) * >>** >> >>Note to the vote: >>+ >>Okay, this will be a simple yes/no question. > > > I believe everything is said about this one. It's OK to remove this and > augment those actions that may still be of use with an additional entry > point. Won't be many actions that qualify, I believe. > > > >>** >>* Continuations Object * >>** >> >>Note to the vote: >>+ >>This is a simple yes/no question too. > > > I don't see the harm but the potential creative uses, so I'm in favour > of keeping it. > > > >>** >>* Modules (input/output) * >>** >> >>Stefano: >> >>>what modules? >> >>I meant the input and output modules. >>I think there is information available in input modules (e.g. static >>global parameters) that could be useful within flows. >> >>Output modules could be useful too. But maybe Christian could >>come up with more detailed explanations. > > > Well, I feared this :-| First off: There is absolutely no *need* to have > those however, they provide _uniform_ access to a lot of stuff that > is often needed and what more. > So the trade off here is to have uniform access and encapsulation versus > additional indirection. IMO we should remove direct access to those > sources and require to go through modules. I would say the exact opposite and my reason is simple: we have one FOM, while input modules are pluggable. just like we agreed to keep one sitemap semantics, I don't see why we should change course on the contract between the flow writer and the way to get input data. > The access is not only uniform across the source but also throughout > cocoon since the modules are available in many places. This is a valid point, even if I see the need of sitemap input modules being lowered a lot with the advent of flow, and your point with it. > The current API is not complete and it would be nice to make it a little > more ECMAscript like e.g. > var foo = Cocoon.input["request-attr"]["foo"] > or > var foo =
Re: [Flow] Preparing the vote - long!
Reinhard Pötz wrote:
**
* FOM (Flow Object model)*
**
Context object
--
--parameters--
getInitParameter(name)
If I interpret this correctly you would provide the web.xml
parameters as properties. Another possibility would be the
attributes. Stefano, what do you think?
IMHO it would be nice to access values like init parameters in a uniform
way. That is what the input modules are all about. Therefore I would
prefer to drop this and make it available through a module instead. Even
though this entails an additional component lookup.
IMHO the same is true for
Session object
--
Cookie object
-
Environment object
--
Question on the environment: Currently the sendPage functions are
implemented using Cocoon.environment:
this.cocoon.forwardTo("cocoon://" +
this.cocoon.environment.getURIPrefix() + uri, bizData, wk);
How can we implement this without the environment object?
Additinally the method cocoon.forwardTo( uri, bizData, wk) is
not available too!
Why would it be difficult to not expose environment but still have it
available for the methods? Sorry if I am super dumb but I haven't looked
at the actual implementation for a while.
**
* Component loading *
**
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.
Fine. Although I don't see the possible abuse here.
**
* statefull components - how to release them?*
**
Sylvain:
1/ raise an error if there are some unreleased stateful components
Until we fully understand this I would go with the above.
**
* Flow and sessions *
**
Note to the vote:
+
So I think we could vote on the current implementation or can anybody
come up with a use case that is not covered with the current
implementation?
Fine.
**
* Map callAction(name,map) *
**
Note to the vote:
+
Okay, this will be a simple yes/no question.
I believe everything is said about this one. It's OK to remove this and
augment those actions that may still be of use with an additional entry
point. Won't be many actions that qualify, I believe.
**
* Continuations Object *
**
Note to the vote:
+
This is a simple yes/no question too.
I don't see the harm but the potential creative uses, so I'm in favour
of keeping it.
**
* Modules (input/output) *
**
Stefano:
what modules?
I meant the input and output modules.
I think there is information available in input modules (e.g. static
global parameters) that could be useful within flows.
Output modules could be useful too. But maybe Christian could
come up with more detailed explanations.
Well, I feared this :-| First off: There is absolutely no *need* to have
those however, they provide _uniform_ access to a lot of stuff that
is often needed and what more.
So the trade off here is to have uniform access and encapsulation versus
additional indirection. IMO we should remove direct access to those
sources and require to go through modules.
The access is not only uniform across the source but also throughout
cocoon since the modules are available in many places.
The current API is not complete and it would be nice to make it a little
more ECMAscript like e.g.
var foo = Cocoon.input["request-attr"]["foo"]
or
var foo = Cocoon.input["request-attr"].get("foo")
.getArray("foo")
.output["request-attr"].set("foo")
.output["request-attr"].commit()
.output["request-attr"].rollback()
Obviously the last two may fuel endless arguments and show that the
first use case was database access. I would perceive this as a
additional discussion than the general module issue.
**
* Script loa
Re: [Flow] Preparing the vote - long!
Reinhard, thank you very much for this great summary of the FOM issues
(and for the Wiki)!
Chris
Reinhard Pötz wrote:
This mail should prepare the upcoming vote on the Cocoon flow
implementation.
Some points are pretty clear but some would need some more comments -
especially
- stateful components -> how to release them?
- continuation object
- o -
Here are the points we should vote on:
**
* FOM (Flow Object model)*
**
Stefano:
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.
Fine. Here you find the updated "small version" of the FOM:
http://wiki.cocoondev.org/Wiki.jsp?page=FOM
The update contains following changes since the initial draft
has been published:
Context object
--
--parameters--
getInitParameter(name)
If I interpret this correctly you would provide the web.xml
parameters as properties. Another possibility would be the
attributes. Stefano, what do you think?
Anyway, I updated the FOM draft at the Cocoon Wiki! containing
both alternatives.
This will be no extra point for the vote but will be part of
the FOM.
Session object
--
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.
Added to the FOM draft.
Cookie object
-
Added name and version property (as suggested by Vadim).
This could be the base for the vote. So please have a look at it!
Environment object
--
Question on the environment: Currently the sendPage functions are
implemented using Cocoon.environment:
this.cocoon.forwardTo("cocoon://" +
this.cocoon.environment.getURIPrefix() + uri, bizData, wk);
How can we implement this without the environment object?
Additinally the method cocoon.forwardTo( uri, bizData, wk) is
not available too!
Notes to the vote:
++
The link http://wiki.cocoondev.org/Wiki.jsp?page=FOM contains
the current status of discussion. We can vote on the complete
draft!
The points
- Script load support
- Modules (input/output)
- Continuations Object
- callAction(..)
are excluded because we should vote on them separatly.
**
* Component loading *
**
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.
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)
I'm not a ECM specialist. Does anybody have an idea how to solve
this? Maybe the "FOM component manager" does a lookup into the
roles and can decide wheter it is a general component or not ...
Note on the vote:
+
So the question at the vote could be:
"Should the flow have only access to general components and
can't access any sitemap components?"
**
* statefull components - how to release them?*
**
Stefano/Ricardo:
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.
Sylvain:
I think there are only two reliable ways to manage stateful
components:
1/ raise an error if there are some unreleased stateful components
when
a continuation is created.
2/ tie releasing of a component to the death of the continuation to
which it belongs.
Solution 1/ so
