Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F081780.4060401@outerthought.org>
Date: Sun, 06 Jul 2003 14:35:12 +0200
From: Marc Portier <mpo@outerthought.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: webMVC essence? (was Re: [RT] Generalizing the flow)
References: <3F058848.9080502@anyware-tech.com> <3F05D752.4070004@verizon.net>
 <3F05F85E.3070501@outerthought.org> <3F061023.9040008@verizon.net>
 <3F06CB3C.4090609@anyware-tech.com> <3F0705E7.5030804@verizon.net>
 <3F072642.6070607@anyware-tech.com> <3F072E5B.3030402@verizon.net>
 <3F0736D3.1020808@anyware-tech.com> <3F07408D.4040106@verizon.net>
 <3F07459B.4040902@anyware-tech.com> <3F074FFD.4030209@outerthought.org>
In-Reply-To: <3F074FFD.4030209@outerthought.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

just adding this little thought I had under the shower:

(possibly helping out the understanding, while slightly off 
topic, if not: never mind)

I was remembering how we started comparing the situation in swing 
apps (and how Chrsitopher easily took down my wicked statement 
that web-apps are so much diferent)

after last nights post I realized the relevant comparison with 
swing apps should be more like the following:

Assume a Main Swing Application that can simultaneously start up 
multiple child windows for controlling parallel instances of the 
same general use case (think for instance about your 
multi-document editor environment)
It is quite likely that each of these child windows will have 
their own instance of a stateful controller (ie as in Controller 
from MVC)


My ideefix in this context has always been that 'there is no such 
thing as webMVC' (see 
http://radio.weblogs.com/0116284/2002/12/11.html for some realy 
old ranting on that)

But honestly I kept strugling with how flowscript was doing 
things... it felt better then the others from the start, but 
couldn't point my finger at it...

sure continuations is a large part of the magic, but there seems 
to be a seperate aspect in the story...

now this recent discussion made me see that most so called 
web-MVC frameworks all work through 'one stateless controller'... 
not so bad: swing apps also work through 'one 
AWT-event-consumption loop' I guess, and dispatching to the 
appropriate widget controllers

(so the difference is not in eventhandling probably)

the big difference is that our pet-MVC approach is allowing to 
have attach a stateful controller to a fresh started 'flow' 
through some specific sub-use case of the complete web-experience 
(as provided by your cocoon-webapp mounted in tomcat).

As said by sylvain: the tree-of-continuations together (with 
their set of local variables they all refer to) actually form 
this concept of 'stateful use case instance' (or statecontroller)


Coming back on my own ideefix we could now probably at least add 
some formal 'test' to the rant:
to apply for the webMVC label the framework in question would 
need an easy way to instantiate and manage parallel stateful 
controllers (hm, sounds like an answer for when the next how do 
you compare cocoon to struts)


Coming back on the proposed namechange that started this 
thread... maybe the realization is the following:
webcontinuations are seemlessly taking up two different aspects
1/ create a flow-context of local variables holding the 'state' 
of the webapp
2/ manage (as seperate nodes in the tree that makes up the above 
context) a set of frozen scripting-language continuations

the namechange proposes to split these aspects up so no scripting 
language implementations could take advantage of the one aspect 
without needing to take up the other.

and as mentioned before, looking at it from the uri/sitemap view 
this seems to fit (it knows about starting and continuing 
flow-control instances, not really about functions and continuations)

regards,
-marc=
(and totally off topic: I find much of this story referencing 
back to one of the other wild ideas of the GeneralizedFlow-wiki: 
last section "leftovers", one before last bullet there: dynamic 
mounted instances of subsitemaps)


Marc Portier wrote:
> 
> 
> Sylvain Wallez wrote:
> 
>> Christopher Oliver wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> Christopher Oliver wrote:
>>>>
>>>>> Sylvain Wallez wrote:
>>>>> <snip>
> 
> 
> 
> <snip/>
> 
>>>
>>>
>>> I don't know, Sylvain. The Sun JVM is also a Java interpreter and so 
>>> is for that matter ATCT itself.  I don't see what's so clumsy about 
>>> "JavaInterpreter".
>>>
>>> Also it looks to me that Alex Krut  is referring to a Java method in 
>>> <map:call function="run"> not a class. "Method" is another name for a 
>>> function, so I really don't see your point. 
>>
>>
>>
>>
>> My mistake, I was too quick when reading the code. You're right, it's 
>> actually a method that is called by reflection. But that doen't change 
>> my opinion : we don't call a function nor an operation : we start a 
>> flow instance (i.e. a continuation tree).
>>
> 
> yes.
> so thanking Christopher for his persistence we might end up at a 
> slightly modified naming proposal?
> 
> <map:call function="..">
> actually is <map:initiate controller="..">
> 
> and
> <map:call continuation=".."> is maybe more of
> <map:continue state="..">
> 
> have to think some more (cause I'm hope for a wording that would fit in 
> the stateless gateways/controllers as well...)
> 
>> Sylvain (going to bed)
>>
> 
> sweet dreams,
> 
> to you too Christopher, thx for investigating some more (mentioned in 
> another reply in this thread) into my possible alternative FlowEngine 
> implementation and accompaning example (try to get by at the event thing 
> for now)
> 
> snipping in from that other mail:
> 
>>> after the above you might see that it in fact makes equal sense as 
>>> 'calling' a 'continuation'
>>>
>>>>
>> No, it does not. You see, a Continuation _really_ _is_ a function 
> 
>  > (in Scheme and in Rhino and in other languages that support
>  > continuations). And you call them like any another function:
> 
>>
>>  var k = new Continuation();
>>  print(k instanceof Function)  // prints true
>>  k(); 
> 
> 
> thx for sharing this detail, had no idea
> (and makes sense all the way)
> 
> but maybe my other mail did a better job at showing what we realy think: 
> 'FlowEngine' is a layer in between:
> 
> Sitemap -> FlowEngine -> Interpreter
> 
> as such, from the sitemap viewpoint it doesn't see functions nor 
> continuations, it just
> 1/ sees uri's mapping to some flowengine-impl that can instantiate 
> application flows that can 'handle' the uri
> 
> 2/ sees uri's mapping to temporary resources and knows about a store 
> that can find back the instance of FlowStateController to 'handle' that uri
> 
> 
> from that angle of view the question is not if Continuation is an 
> instance of Function (that is great stuff inside the Interpreter)
> 
> the question is can there be a FlowStateController that can be fulfilled 
> by WebContinuationController (the one calling the continuation-function) 
> and InteractionInstance (my example)
> 
> 
> (feeling we are getting rid of the smoke on both sides?)
> 
> regards,
> 
> -marc= (enjoying fireworks from his home-office-window as we speak, last 
> shot means the party and the noise is over and I can go to sleep as well 
> :-))
> 
> PS: probably will not be able to get back to you on this before monday...

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org