You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2002/12/04 12:26:42 UTC
Changes made to flow system.js
Hi Troops!
Hope all is well.
I've just checked in BZ#14903 which changes the names of the flow
sendPage* functions as previously discussed in the 'flow wishlist'
thread.
Unfortunately the change is *not* backwards compatible so please be
careful and update any flow code you might have locally after updating.
The changes are:
sendPage() becomes sendPageAndWait()
sendPageAndContinue() becomes sendPage()
The last one is the tricky one because the method names are
essentially swapped.
The changes themselves were discussed in the following threads:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103796994100696&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103798846821855&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103834225818942&w=2
If there's any problems please let me know.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Jason Foster wrote:
> <snip/>
>
> How about thinking in terms of synchronous and asynchronous I/O?
>
> sendPageAndBlock() or sendPageSync()
> sendPageAsync()
Nah, it might even get more confusing.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Melhem wrote:
> So does this mean you can send
> multiple pages back to the client without client intereaction.. ?
Remember: no matter how complex cocoon becomes internally, a servlet is
*always* a servlet and an HTTP response is always an HTTP response.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Marc Portier <mp...@outerthought.org>.
disclaimer:
this is at the danger of making a complete fool of myself
have only been following this discussion from a distance
so here is the fool's thought:
1. Given the fact that: you could still do things according to:
>>>"Finish" what? The problem with that is that you could still do things
>>>after the page was sent back to the client. Advanced users might want
>>>to use this fact to do all sorts of nasty things.
2. My experience with method-names containing "and" is that they
point out some bad SoC... typically if you have multiple ones it
actually shows the semantics are to be split up into two methods:
So from a clueless end-user-point of view (just seeking semantics
per se) I guess
sendPage(); //doing just that, leaving plenty of room to do
other stuff (while the client gets an answer back already?)
either or not followed by
continue();
wait();
saveState();
prepareForContinuation();
noneOfTheAbove();
would make the most common sense... but maybe is changing a bit
the use cases/current approach?
>>
>>Interesting, didnt think of that. So does this mean you can send
>>multiple pages back to the client without client intereaction.. ?
>
>
> Don't think so (because the browser is not listening). But you could
> write a document locally (to a file) or if we had an EmailSerializer
> one could send an email or ... like
>
> ....
> sendPageAndContinue("Confimation.email");
> sendPageAndBlock("Confirmation.xml"); // or whatever name it is currently
> ....
>
> Chris.
multiple sendPage()'s after each other should then result in some
exception since the first one would of have done something like
'closed' the Httpresponse's printStream (or at least sent out the
HTTP response header, I think the servlet API has a method for
checking this)
as for sending email: I think it makes sense to call that
sendEmail() (from a semantical point of view... but this is
probably blasphemy to anyone that ever considered an
emailSerializer as something usefull)
regards,
-marc=
PS: don't flame my stupidity here, pointers to obvious stuff I
missed are welcome
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 06.Dec.2002 -- 11:09 AM, Michael Melhem wrote:
> On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
> > "Finish" what? The problem with that is that you could still do things
> > after the page was sent back to the client. Advanced users might want
> > to use this fact to do all sorts of nasty things.
>
> Interesting, didnt think of that. So does this mean you can send
> multiple pages back to the client without client intereaction.. ?
Don't think so (because the browser is not listening). But you could
write a document locally (to a file) or if we had an EmailSerializer
one could send an email or ... like
....
sendPageAndContinue("Confimation.email");
sendPageAndBlock("Confirmation.xml"); // or whatever name it is currently
....
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
On Friday, Dec 6, 2002, at 02:09 US/Pacific, Michael Melhem wrote:
> On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
>>
>> On Thursday, Dec 5, 2002, at 02:13 US/Pacific, Michael Melhem wrote:
>>
>>> Hmmmm.. we could end up disussing semantics forever,
>>> but how about "sendPageAndFinish" ? Thats the only alternative i can
>>> think of
>>> at the moment. So one would have:
>>>
>>> flow()
>>> {
>>> sendPageAndWait
>>> ..
>>> sendPageAndWait
>>> ..
>>> sendPageAndFinish
>>> }
>>
>> "Finish" what? The problem with that is that you could still do things
>> after the page was sent back to the client. Advanced users might want
>> to use this fact to do all sorts of nasty things.
>
> Interesting, didnt think of that. So does this mean you can send
> multiple pages back to the client without client intereaction.. ?
Yes, this makes perfect sense when dealing with some asynchronous Web
services. Some of the protocols out there require the server to send a
quick response saying "I've received your request, I'll process it and
send you the response". The actual response comes as an asynchronous
request back to the client (which becomes a server while processing
this "response").
In the servlet world however, as Stefano noted, this doesn't make much
sense.
Cheers,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
>
> On Thursday, Dec 5, 2002, at 02:13 US/Pacific, Michael Melhem wrote:
>
> >On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
> >>Ovidiu Predescu wrote:
> >>
> >>>I think the danger is to have the semantics of these functions
> >>>associated with the way the response page is actually sent over the
> >>>wire.
> >>>
> >>>To reiterate my option, I think sendPageAndWait and
> >>>sendPageAndContinue are still the best options. They also provide the
> >>>maximum compatibility with the old naming, only sendPage dissapears,
> >>>everything else is the same.
> >>
> >>
> >>Agree. I think the confusion of "sendPageAndContinue" with
> >>continuations
> >>came from the fact that the "sendPage" counterpart wasn't semantically
> >>precise enough.
> >>
> >>Most people seem to agree that "sendPageAndWait" is a good name. My
> >>english skills tell me that "continue" is a good word as a
> >>complementary
> >>to "wait". And since my skills are somewhat limited, it's likely that
> >>it
> >>most people will have the same understanding as me :)
> >>
> >>So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
> >>being equally-precise and semantically complementary.
> >
> >
> >Yes I agree (like most) that sendPageAndWait is the best name, because
> >it
> >implies that flow "waits" here for a response. (even though
> >techinically
> >this is not true)
> >
> >+1
> >
> >The "wait" here is in the context of the of the flow method...its the
> >flow
> >method that waits..but continue in sendPageAndContinue makes sense
> >only in the
> >context of the sitemap processing, its the sitemap that continues its
> >processing. This requires a context change in understanding which I
> >find
> >confusing (and breaks the wait/continue symmetry). Without this
> >context shift,
> >one might think its that the flow method that continues - as apposed
> >to waiting.
Hi Ovidui!
>
> No, Michael, is not the sitemap that continues the processing.
> sendPageAndContinue will _temporarily_ pass the control to the sitemap
> to generate the response. After the response is generated, the control
> is returned to the control flow script. The "Continue" refers to the
> fact that the function in which sendPageAndContinue appears will
> continue to execute, _after_ the response was sent back to the client.
Oh, I was under the impression that sendPage(AndContinue)() would
actually _exit_ the flow method because I have always used it (and seen it
used) like that. Sorry about the confusion!
So in this sense Wait/Continue _do_ fit well together semantically. ;)
>
> >Also, a flow method need not have a "sendPageAndWait". Example:
> >
> > flow()
> > {
> > .....
> >
> > if (something)
> > sendPageAndContiue(page1)
> > else
> > sendPageAndContiue(page2)
> > }
> >
> >so in this case, continue could be interepted as "create continuation"
> >as there
> >is no "wait" to contrast it with.
>
> It should not be. With the proper documentation (I know, I know ;)
> things should be clear on the meaning and "Wait" and "Continue" in this
> context.
Hmm...perhaps your right, with documentation (and time) we can dissassociate
Continue from continuations.
>
> >So as for sendPageAndContinue, I vote
> >
> >-0.25 (hmm .. im not totally against it)
> >
> >Hmmmm.. we could end up disussing semantics forever,
> >but how about "sendPageAndFinish" ? Thats the only alternative i can
> >think of
> >at the moment. So one would have:
> >
> > flow()
> > {
> > sendPageAndWait
> > ..
> > sendPageAndWait
> > ..
> > sendPageAndFinish
> > }
>
> "Finish" what? The problem with that is that you could still do things
> after the page was sent back to the client. Advanced users might want
> to use this fact to do all sorts of nasty things.
Interesting, didnt think of that. So does this mean you can send
multiple pages back to the client without client intereaction.. ?
Regrads,
Michael Melhem
>
> Cheers,
> Ovidiu
>
> --
> Ovidiu Predescu <ov...@apache.org>
> http://webweavertech.com/ovidiu/weblog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
On Thursday, Dec 5, 2002, at 02:13 US/Pacific, Michael Melhem wrote:
> On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
>> Ovidiu Predescu wrote:
>>
>>> I think the danger is to have the semantics of these functions
>>> associated with the way the response page is actually sent over the
>>> wire.
>>>
>>> To reiterate my option, I think sendPageAndWait and
>>> sendPageAndContinue are still the best options. They also provide the
>>> maximum compatibility with the old naming, only sendPage dissapears,
>>> everything else is the same.
>>
>>
>> Agree. I think the confusion of "sendPageAndContinue" with
>> continuations
>> came from the fact that the "sendPage" counterpart wasn't semantically
>> precise enough.
>>
>> Most people seem to agree that "sendPageAndWait" is a good name. My
>> english skills tell me that "continue" is a good word as a
>> complementary
>> to "wait". And since my skills are somewhat limited, it's likely that
>> it
>> most people will have the same understanding as me :)
>>
>> So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
>> being equally-precise and semantically complementary.
>
>
> Yes I agree (like most) that sendPageAndWait is the best name, because
> it
> implies that flow "waits" here for a response. (even though
> techinically
> this is not true)
>
> +1
>
> The "wait" here is in the context of the of the flow method...its the
> flow
> method that waits..but continue in sendPageAndContinue makes sense
> only in the
> context of the sitemap processing, its the sitemap that continues its
> processing. This requires a context change in understanding which I
> find
> confusing (and breaks the wait/continue symmetry). Without this
> context shift,
> one might think its that the flow method that continues - as apposed
> to waiting.
No, Michael, is not the sitemap that continues the processing.
sendPageAndContinue will _temporarily_ pass the control to the sitemap
to generate the response. After the response is generated, the control
is returned to the control flow script. The "Continue" refers to the
fact that the function in which sendPageAndContinue appears will
continue to execute, _after_ the response was sent back to the client.
> Also, a flow method need not have a "sendPageAndWait". Example:
>
> flow()
> {
> .....
>
> if (something)
> sendPageAndContiue(page1)
> else
> sendPageAndContiue(page2)
> }
>
> so in this case, continue could be interepted as "create continuation"
> as there
> is no "wait" to contrast it with.
It should not be. With the proper documentation (I know, I know ;)
things should be clear on the meaning and "Wait" and "Continue" in this
context.
> So as for sendPageAndContinue, I vote
>
> -0.25 (hmm .. im not totally against it)
>
> Hmmmm.. we could end up disussing semantics forever,
> but how about "sendPageAndFinish" ? Thats the only alternative i can
> think of
> at the moment. So one would have:
>
> flow()
> {
> sendPageAndWait
> ..
> sendPageAndWait
> ..
> sendPageAndFinish
> }
"Finish" what? The problem with that is that you could still do things
after the page was sent back to the client. Advanced users might want
to use this fact to do all sorts of nasty things.
Cheers,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
> Ovidiu Predescu wrote:
>
> >
> >On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:
> >
> >><snip/>
> >>
> >>How about thinking in terms of synchronous and asynchronous I/O?
> >>
> >>sendPageAndBlock() or sendPageSync()
> >>sendPageAsync()
> >
> >
> >On Wednesday, Dec 4, 2002, at 14:33 US/Pacific, Andy Lewis wrote:
> >
> >>
> >>what about I/O terms?
> >>
> >>sendPageBlocking
> >>sendPageNonBlocking
> >>
> >>or something akin to these?
> >
> >
> >I think the danger is to have the semantics of these functions
> >associated with the way the response page is actually sent over the wire.
> >
> >To reiterate my option, I think sendPageAndWait and
> >sendPageAndContinue are still the best options. They also provide the
> >maximum compatibility with the old naming, only sendPage dissapears,
> >everything else is the same.
>
>
> Agree. I think the confusion of "sendPageAndContinue" with continuations
> came from the fact that the "sendPage" counterpart wasn't semantically
> precise enough.
>
> Most people seem to agree that "sendPageAndWait" is a good name. My
> english skills tell me that "continue" is a good word as a complementary
> to "wait". And since my skills are somewhat limited, it's likely that it
> most people will have the same understanding as me :)
>
> So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
> being equally-precise and semantically complementary.
Yes I agree (like most) that sendPageAndWait is the best name, because it
implies that flow "waits" here for a response. (even though techinically
this is not true)
+1
The "wait" here is in the context of the of the flow method...its the flow
method that waits..but continue in sendPageAndContinue makes sense only in the
context of the sitemap processing, its the sitemap that continues its
processing. This requires a context change in understanding which I find
confusing (and breaks the wait/continue symmetry). Without this context shift,
one might think its that the flow method that continues - as apposed to waiting.
Also, a flow method need not have a "sendPageAndWait". Example:
flow()
{
.....
if (something)
sendPageAndContiue(page1)
else
sendPageAndContiue(page2)
}
so in this case, continue could be interepted as "create continuation" as there
is no "wait" to contrast it with.
So as for sendPageAndContinue, I vote
-0.25 (hmm .. im not totally against it)
Hmmmm.. we could end up disussing semantics forever,
but how about "sendPageAndFinish" ? Thats the only alternative i can think of
at the moment. So one would have:
flow()
{
sendPageAndWait
..
sendPageAndWait
..
sendPageAndFinish
}
Best regards,
Michael Melhem
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
>
> On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:
>
>> <snip/>
>>
>> How about thinking in terms of synchronous and asynchronous I/O?
>>
>> sendPageAndBlock() or sendPageSync()
>> sendPageAsync()
>
>
> On Wednesday, Dec 4, 2002, at 14:33 US/Pacific, Andy Lewis wrote:
>
>>
>> what about I/O terms?
>>
>> sendPageBlocking
>> sendPageNonBlocking
>>
>> or something akin to these?
>
>
> I think the danger is to have the semantics of these functions
> associated with the way the response page is actually sent over the wire.
>
> To reiterate my option, I think sendPageAndWait and
> sendPageAndContinue are still the best options. They also provide the
> maximum compatibility with the old naming, only sendPage dissapears,
> everything else is the same.
Agree. I think the confusion of "sendPageAndContinue" with continuations
came from the fact that the "sendPage" counterpart wasn't semantically
precise enough.
Most people seem to agree that "sendPageAndWait" is a good name. My
english skills tell me that "continue" is a good word as a complementary
to "wait". And since my skills are somewhat limited, it's likely that it
most people will have the same understanding as me :)
So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
being equally-precise and semantically complementary.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:
> <snip/>
>
> How about thinking in terms of synchronous and asynchronous I/O?
>
> sendPageAndBlock() or sendPageSync()
> sendPageAsync()
On Wednesday, Dec 4, 2002, at 14:33 US/Pacific, Andy Lewis wrote:
>
> what about I/O terms?
>
> sendPageBlocking
> sendPageNonBlocking
>
> or something akin to these?
I think the danger is to have the semantics of these functions
associated with the way the response page is actually sent over the
wire.
To reiterate my option, I think sendPageAndWait and sendPageAndContinue
are still the best options. They also provide the maximum compatibility
with the old naming, only sendPage dissapears, everything else is the
same.
Regards,
Ovidiu
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Jason Foster <jf...@uwo.ca>.
<snip/>
How about thinking in terms of synchronous and asynchronous I/O?
sendPageAndBlock() or sendPageSync()
sendPageAsync()
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Artur Bialecki wrote:
> How about:
>
> sendAndSuspend
this is kind of cool, even if I still like 'sendPageAndWait' more
> sendAndResume
Hmmm, this seems to convey the wrong message since it's the system that
resumes the execution, not your call to this method.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Changes made to flow system.js
Posted by Artur Bialecki <ar...@digitalfairway.com>.
How about:
sendAndSuspend
sendAndResume
Artur...
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: December 4, 2002 4:07 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Changes made to flow system.js
>
>
> Sylvain Wallez wrote:
> > Michael Melhem wrote:
> >
> >> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
> >>
> >>
> >>> Marcus Crafter wrote:
> >>>
> >>>> Hi Troops!
> >>>>
> >>>> Hope all is well.
> >>>>
> >>>> I've just checked in BZ#14903 which changes the names of the
> >>>> flow sendPage* functions as previously discussed in
> the 'flow
> >>>> wishlist' thread.
> >>>>
> >>>> Unfortunately the change is *not* backwards
> compatible so please
> >>>> be careful and update any flow code you might have
> locally after
> >>>> updating.
> >>>>
> >>>> The changes are:
> >>>>
> >>>> sendPage() becomes sendPageAndWait()
> >>>> sendPageAndContinue() becomes sendPage()
> >>>>
> >>>> The last one is the tricky one because the method names are
> >>>> essentially swapped.
> >>>>
> >>>>
> >>>
> >>> Just some thoughts (sorry if this already has been
> discussed, I may
> >>> have missed it) : why not keeping the "sendPageAndContinue" ?
> >>>
> >>
> >>
> >> sendPageAndContinue is precisely the problem, many people were
> >> confusing "Continue" with continuations!
> >>
> >>
> >
> > Ah, ok, I understand... but I'm still uncomfortable with having a
> > precise "sendPageAndWait" and an imprecise "sendPage", as
> inconsistent
> > naming always leads to confusion.
> >
> > So, last try : what about "sendPageAndReturn" ?
>
> I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
> that much, but it's true that 'sendPage' contains less
> semantic meaning
> than 'sendPageAndWait' and therefore might become a little
> confusing at
> first. It's a little bit semantically unbalanced and this doesn't
> reflect in their functional operation.
>
> So, let's see, that method is supposed to 'send a page' to the client
> but is not going to wait for the client to come back and
> continue. So,
> the real name would be something like
>
> - sendPageAndDontWait
>
> but that sucks.
>
> - sendPageAndReturn
>
> is nice but only if you understand that the flow layer takes control
> over the sitemap and that 'return' means that you are returning from
> procedural continuation-based control (the flowscript) to declerative
> request driven control (the sitemap)
>
> So it does have perfect sense for us, but I'm not sure it does for
> somebody that looks at the flowscript for the first time.
>
> But I can't come up with anything better because
>
> - sendPageAndExit
>
> might be even worse (people might think Cocoon might stop!)
>
> Any idea?
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Christian Haul" <ha...@dvs1.informatik.tu-darmstadt.de>
> On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:
>
> <snip/>
>
> > Please cast your votes on:
> >
> > - maintaining the old naming conventions and providing the above
> > aliases for sendPage* functions; here's my +1.
>
> +1
+1
>
> > - further discussions on an alternative API for sendPage; here's my +1.
>
> +1
-0
Konstantin
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:
<snip/>
> Please cast your votes on:
>
> - maintaining the old naming conventions and providing the above
> aliases for sendPage* functions; here's my +1.
+1
> - further discussions on an alternative API for sendPage; here's my +1.
+1
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ugo Cei <u....@cbim.it>.
Ovidiu Predescu wrote:
> OK, let's wrap up this discussion.
>
> What I'll do is revert to the old naming and at the same time provide
> some useful aliases for the default functions.
>
> sendPage <=> sendPageAndWait
>
> sendPageAndContinue <=> sendPageNoWait
>
> This means the sendPage() function will also be accessible as
> sendPageAndWait(), and sendPageAndContinue() will be accessible as
> sendPageNoWait().
>
> Since in JavaScript functions are objects, if you don't like the default
> names you can just assign them a new name without any penalty in runtime
> performance:
>
> var sendPageWithSomeNewIllustrativeName;
>
> sendPageWithSomeNewIllustrativeName = sendPage;
>
> and so on.
Oh no. Apart from stinking of FS, don't you think that this is going to
confuse the hell out of whomever is going to debug your scripts in the
future?
If I were a commiter, I'd express my -1 on this ;-).
> I would like us to spend our energy in discussing better things that
> names (and, ahem, implementing and documenting them). For some reasons
> discussions on names seem to provide the most heated debates.
Agreed. I stopped following naming thread after the first two or three
messages. And I have already switched from sendPage/sendPageAndContinue
to sendPageAndWait/sendPage, so I'd like not to switch back. So my
proposal (not a vote) is to keep things as they are now, i.e. sendPage
and sendPageAndWait.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ugo Cei <u....@cbim.it>.
Ovidiu Predescu wrote:
> Ugo expressed his -1 on it but I do hope he would change his opinion.
> Although he's not a committer I do value his opinion ;)
My opinion is biased by the fact that I've already started coding using
the new names, but I cannot tell you not to go on with whatever you've
decided just because I don't know how to do a global search&replace ;-).
What I don't like is the idea of having aliases. Beginners are going to
be confused by this, docs and examples will use one alias here and
another one there. So, my opinion is: pick whatever names seem more fit
and stick to them.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> I'd like to start working on the control flow documentation ASAP and I
> was wondering what is the status on the naming convention proposal I
> made a while ago.
>
> So far I've counted three +1 votes for reverting back to the old naming
> convention and providing the following aliases:
>
> sendPage <=> sendPageAndWait (this function provides the blocking
> functionality, the response is sent, the continuation captured and the
> script execution stops)
>
> sendPageAndContinue <=> sendPageNoWait (this function sends the response
> and continues the script execution)
I'm against aliases as well.
I'd say let's go for the new terminology and let's stick with that once
and forever.
People can do a find/replace for now but at least they won't find
scripts with all four methods floating around the internet.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ovidiu Predescu <ov...@apache.org>.
I'd like to start working on the control flow documentation ASAP and I
was wondering what is the status on the naming convention proposal I
made a while ago.
So far I've counted three +1 votes for reverting back to the old naming
convention and providing the following aliases:
sendPage <=> sendPageAndWait (this function provides the blocking
functionality, the response is sent, the continuation captured and the
script execution stops)
sendPageAndContinue <=> sendPageNoWait (this function sends the
response and continues the script execution)
Ugo expressed his -1 on it but I do hope he would change his opinion.
Although he's not a committer I do value his opinion ;)
Most of the docs and presentations I've written so far refer to the old
naming convention. All the past emails on the mailing list explaining
what the control flow is and how it works use the old convention name,
with sendPage() being the blocking function, not the pass-through one
we currently have. I think is important to maintain this understanding,
otherwise we'll end up confusing a lot of people.
Please cast your votes on whether you wish to revert to the old naming
convention and providing aliases as described above and in the message
cited below.
Best regards,
Ovidiu
On Monday, Dec 9, 2002, at 10:40 US/Pacific, Ovidiu Predescu wrote:
> OK, let's wrap up this discussion.
>
> What I'll do is revert to the old naming and at the same time provide
> some useful aliases for the default functions.
>
> sendPage <=> sendPageAndWait
>
> sendPageAndContinue <=> sendPageNoWait
>
> This means the sendPage() function will also be accessible as
> sendPageAndWait(), and sendPageAndContinue() will be accessible as
> sendPageNoWait().
>
> Since in JavaScript functions are objects, if you don't like the
> default names you can just assign them a new name without any penalty
> in runtime performance:
>
> var sendPageWithSomeNewIllustrativeName;
>
> sendPageWithSomeNewIllustrativeName = sendPage;
>
> and so on.
>
> I'll make sure in the documentation we mention the above.
>
> I would like us to spend our energy in discussing better things that
> names (and, ahem, implementing and documenting them). For some reasons
> discussions on names seem to provide the most heated debates.
>
> We can also split the current functionality of sendPage in two
> functions as described by Marc and Giacomo, but I'd consider this
> functionality to be for advanced usages. This should be an alternative
> API for the much simpler sendPage API, and not a replacement for it.
> Several people on this list outlined this functionality, let's
> crystalize these discussions and come up with a good API for it.
>
> Please cast your votes on:
>
> - maintaining the old naming conventions and providing the above
> aliases for sendPage* functions; here's my +1.
>
> - further discussions on an alternative API for sendPage; here's my +1.
>
> Regards,
> Ovidiu
>
> On Monday, Dec 9, 2002, at 00:38 US/Pacific, Christian Haul wrote:
>
>> On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:
>>> Hmmmm, hmmm, hmmm, ok, ok, what about something radically different
>>> like
>>>
>>> getUserInputFromScreen(uri)
>>>
>>> to replace sendPageAndWait()?
>>
>> Only that this function returns void which is again misleading. I
>> would expect a function named "get...." to return a value.
>>
>> I'm all with Christopher: revert to "sendPage" and have some ugly name
>> for the special case where no continuation is created. But then we are
>> back to start :-(
>>
>> Splitting it up like Marc suggested would be another option only that
>> 95% will write their own wrapper around this since the natural use is
>> all three together (create id + send page + create continuation). OTOH
>> there would be interesting uses if one could slip in code between
>> create id and send page.
>>
>> Of course we could split it up and provide a convenience function.
>>
>> Chris.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Wrap-up for flow functions [WAS Re: Changes made to flow system.js]
Posted by Ovidiu Predescu <ov...@apache.org>.
OK, let's wrap up this discussion.
What I'll do is revert to the old naming and at the same time provide
some useful aliases for the default functions.
sendPage <=> sendPageAndWait
sendPageAndContinue <=> sendPageNoWait
This means the sendPage() function will also be accessible as
sendPageAndWait(), and sendPageAndContinue() will be accessible as
sendPageNoWait().
Since in JavaScript functions are objects, if you don't like the
default names you can just assign them a new name without any penalty
in runtime performance:
var sendPageWithSomeNewIllustrativeName;
sendPageWithSomeNewIllustrativeName = sendPage;
and so on.
I'll make sure in the documentation we mention the above.
I would like us to spend our energy in discussing better things that
names (and, ahem, implementing and documenting them). For some reasons
discussions on names seem to provide the most heated debates.
We can also split the current functionality of sendPage in two
functions as described by Marc and Giacomo, but I'd consider this
functionality to be for advanced usages. This should be an alternative
API for the much simpler sendPage API, and not a replacement for it.
Several people on this list outlined this functionality, let's
crystalize these discussions and come up with a good API for it.
Please cast your votes on:
- maintaining the old naming conventions and providing the above
aliases for sendPage* functions; here's my +1.
- further discussions on an alternative API for sendPage; here's my +1.
Regards,
Ovidiu
On Monday, Dec 9, 2002, at 00:38 US/Pacific, Christian Haul wrote:
> On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:
>> Hmmmm, hmmm, hmmm, ok, ok, what about something radically different
>> like
>>
>> getUserInputFromScreen(uri)
>>
>> to replace sendPageAndWait()?
>
> Only that this function returns void which is again misleading. I
> would expect a function named "get...." to return a value.
>
> I'm all with Christopher: revert to "sendPage" and have some ugly name
> for the special case where no continuation is created. But then we are
> back to start :-(
>
> Splitting it up like Marc suggested would be another option only that
> 95% will write their own wrapper around this since the natural use is
> all three together (create id + send page + create continuation). OTOH
> there would be interesting uses if one could slip in code between
> create id and send page.
>
> Of course we could split it up and provide a convenience function.
>
> Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:
> Hmmmm, hmmm, hmmm, ok, ok, what about something radically different like
>
> getUserInputFromScreen(uri)
>
> to replace sendPageAndWait()?
Only that this function returns void which is again misleading. I
would expect a function named "get...." to return a value.
I'm all with Christopher: revert to "sendPage" and have some ugly name
for the special case where no continuation is created. But then we are
back to start :-(
Splitting it up like Marc suggested would be another option only that
95% will write their own wrapper around this since the natural use is
all three together (create id + send page + create continuation). OTOH
there would be interesting uses if one could slip in code between
create id and send page.
Of course we could split it up and provide a convenience function.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]
Posted by Ovidiu Predescu <ov...@apache.org>.
On Tuesday, Dec 10, 2002, at 12:36 US/Pacific, Stefano Mazzocchi wrote:
> Ovidiu, I know that some of you are somewhat frustrated by this
> 'apparently nonsense' discussion on some trivial things like function
> names, but I personally think that a great deal of information was
> exchanged between people on flow and this is a great thing.
Yes, indeed, this discussion helped clarify a lot of misunderstanding
people had about flow. I've never said it was nonsense, I just wanted
to reach a logical conclusion. I'm concerned about the bandwidth we
spend on such unimportant issues, instead of discussing the real meat
of the problem. It's getting more and more a discussion about form
instead of content.
> Also, I think Chris is right on target with this, so, if you don't
> mind, I'll continue the discussion until we have reached consensus.
Chris helped indeed a great deal in clarifying the misunderstanding I
mentioned above. It looks like some of them still persist, I'll reply
to some of those later in this message.
> I know that javascript allows you to redefine your function names
> easily, but that's working around the problem and it doesn't help to
> create consensus, without with the community might develop friction
> and frustration even more than during the discussions.
I don't think naming conventions will create frictions in the nice
community of people we have here, it's the design issues which usually
create frictions. From this thread however, I see discussed only
function names, and not the design aspects of the control flow. I don't
a consensus can be reached on names, so IMO it's better to decide on
something good enough and stick with it.
> Anyway, feel free to ignore this discussion if you don't care about it.
Ahem, but would you ignore a discussion that consumes such a bandwidth?
;)
>> So here are some other possibilities:
>> [...]
>> 2) Explicitly identify the input page, such as
>> sendForm(uri, bizData); // block waiting for user input;
>> cocoon.request contains the submitted request after this returns
>> and
>> sendPage(uri, bizData); // send a page that won't return here;
>> cocoon.request is invalid after this returns
>
> [...]
>
> So, my proposal would be
>
> sendScreen(uri, data);
>
> - sends the screen containing a form that will trigger a POST
> action that will go back here
> - blocks the execution of the flow until a request with the
> matching continuation ID comes back
> - returns with the cocoon.* objects filled with the latest client
> data
>
> sendPage(uri, data);
>
> - sends a page
> (no further rountripping is expected from that page so no state is
> transparently preserved)
>
> - o -
>
> I have an alternative proposal, even if this requires more changes to
> the system:
>
> Instead of "sendScreen", why don't we do:
>
> var objectModel = getClientInput(uri,data);
>
> then
>
> sendPage(uri);
>
> getClientInput will *implicitly* have a blocking semantics. I know
> this explicitly outlines the third step, but IMO this solves one
> cognitive problem that I had when Ovidiu first described the flow: how
> I get the client data back from sendPage()?
>
> Having the data *explicitly* returned from the method invocation is,
> IMO, a *GREAT* help.
The original sendPage() function already returns something: it's the
continuation object. This object cannot be returned in any other way
from sendPage(). Even though normal users will never use it, it's still
a good idea to have that object available for advanced scripts.
Stefano, all the API change proposals I've seen so far can be
implemented easily in few lines of code in JavaScript. My take on this
is that is not worth spending our time (not to mention eating Apache's
bandwidth ;) analyzing each and every possible API we can come up with.
Instead of doing that, we can have the simple API already in place, and
build on top of it, or rip it apart and implement a custom one in
various applications. We'll see later what works and what not. And
since each application is unique, experienced developers will come up
with their own higher level abstractions on top of what is already
here. This is not an issue at all, there are always better ways to do
things.
We desperately need some documentation for the current features and
various other things to be finished, before this stuff can become
production quality. I'd suggest these naming discussions to stop here,
and instead focus on the places where the real work still needs to be
done. My time is limited, so I'd really appreciate any help in those
areas.
I hope this doesn't sound offensive, it's certainly not meant to be so.
Best regards,
Ovidiu
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow
system.js]
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu, I know that some of you are somewhat frustrated by this
'apparently nonsense' discussion on some trivial things like function
names, but I personally think that a great deal of information was
exchanged between people on flow and this is a great thing.
Also, I think Chris is right on target with this, so, if you don't mind,
I'll continue the discussion until we have reached consensus.
I know that javascript allows you to redefine your function names
easily, but that's working around the problem and it doesn't help to
create consensus, without with the community might develop friction and
frustration even more than during the discussions.
Anyway, feel free to ignore this discussion if you don't care about it.
Christopher Oliver wrote:
> Yes, another way of looking at it is that (from the flow script's point
> of view) sendPageAndWait()
>
> 1) displays a form page in the client's browser
> 2) waits for the form to be submitted (which becomes available to the
> script as the cocoon.request property)
> 3) returns
>
> So this function describes a round trip interaction.
Yep.
> I believe in
> Christian Queinnec's original (scheme) code he called this function
> simply "show". Thus like "sendPage" his name focused on the first leg of
> the trip. Other names like,
>
> getReply()
> getUserInput(uri, bizData)
>
> focus on the return leg of the round trip. I think both are valid
> (partial) descriptions of the function's behavior. I don't think one or
> the other is superior. And combined names like sendPageAndWait or
> sendPageAndGetUserInput() seem overly explicit and ugly.
Very good description.
> So here are some other possibilities:
>
> 1) Revert to the nice
>
> sendPage(uri, bizData);
>
> instead of the ugly sendPageAndWait() and use something ugly and
> explicit like
>
> sendPageNoWait(uri, bizData);
>
> instead of sendPageAndContinue();
>
> 2) Explicitly identify the input page, such as
>
> sendForm(uri, bizData); // block waiting for user input;
> cocoon.request contains the submitted request after this returns
>
> and
>
> sendPage(uri, bizData); // send a page that won't return here;
> cocoon.request is invalid after this returns
Ohhhh, nice!!!
What I like about this is that semantics are abstract enough to mean
anything, but they don't confuse people!
more about this below.
> 3) Punt on distinguishing this behavior with the name of the function.
> Just add a third (optional) boolean parameter to indicate if it should
> block
>
> sendPage(uri, bizData, waitForInput);
I like the above better.
What I mostly like is the distinction between a 'form' and a 'page'.
The way I've been programming web application is that POST and GET
actions should be connected to the same resource.
I mean, if I have to POST something, first of all I GET it, then fill up
the form, then POST it, then get results. All good webapp frameworks try
to enforce the notion of this in-resource roundtripping.
This is also because a page can contain *more* than one form.
For this reason, I would propose to change the notion from 'form' to
'screen' to avoid having the semantic collision between what a 'form' is
for flow and what a form is for HTML.
So, my proposal would be
sendScreen(uri, data);
- sends the screen containing a form that will trigger a POST action
that will go back here
- blocks the execution of the flow until a request with the matching
continuation ID comes back
- returns with the cocoon.* objects filled with the latest client data
sendPage(uri, data);
- sends a page
(no further rountripping is expected from that page so no state is
transparently preserved)
- o -
I have an alternative proposal, even if this requires more changes to
the system:
Instead of "sendScreen", why don't we do:
var objectModel = getClientInput(uri,data);
then
sendPage(uri);
getClientInput will *implicitly* have a blocking semantics. I know this
explicitly outlines the third step, but IMO this solves one cognitive
problem that I had when Ovidiu first described the flow: how I get the
client data back from sendPage()?
Having the data *explicitly* returned from the method invocation is,
IMO, a *GREAT* help.
What do you think?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Christopher Oliver <re...@verizon.net>.
Stefano Mazzocchi wrote:
> Miles Elam wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>
>>> Look at what sendPageAndWait() is supposed to do:
>>>
>>> 1) create the continuation object
>>> 2) store it someplace
>>> 3) get its id
>>> 4) invoque the sitemap with the required URI
>>> 5) pass the invocation parameters and the continuation id
>>
>>
>>
>
> You got me thinking that 'sendPage' (with and without 'AndWait') is
> wrong semantics because it focus the attention on getting the page
> out, instead of focusing on waiting until the data is received.
>
> 'waiting' in a continuation-wise sense, of course.
>
> i think that if we focus our semantics on the 'way-back' from the
> client instead that on the 'way-up' to it, we might gain further
> explicitness.
>
> What do you people think?
>
Yes, another way of looking at it is that (from the flow script's point
of view) sendPageAndWait()
1) displays a form page in the client's browser
2) waits for the form to be submitted (which becomes available to the
script as the cocoon.request property)
3) returns
So this function describes a round trip interaction. I believe in
Christian Queinnec's original (scheme) code he called this function
simply "show". Thus like "sendPage" his name focused on the first leg of
the trip. Other names like,
getReply()
getUserInput(uri, bizData)
focus on the return leg of the round trip. I think both are valid
(partial) descriptions of the function's behavior. I don't think one or
the other is superior. And combined names like sendPageAndWait or
sendPageAndGetUserInput() seem overly explicit and ugly.
So here are some other possibilities:
1) Revert to the nice
sendPage(uri, bizData);
instead of the ugly sendPageAndWait() and use something ugly and
explicit like
sendPageNoWait(uri, bizData);
instead of sendPageAndContinue();
2) Explicitly identify the input page, such as
sendForm(uri, bizData); // block waiting for user input;
cocoon.request contains the submitted request after this returns
and
sendPage(uri, bizData); // send a page that won't return here;
cocoon.request is invalid after this returns
3) Punt on distinguishing this behavior with the name of the function.
Just add a third (optional) boolean parameter to indicate if it should block
sendPage(uri, bizData, waitForInput);
Regards,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Miles Elam wrote:
> Stefano Mazzocchi wrote:
>
>> No, because there is a state-preserving channel (a connection) between
>> you and the database. On the web or any other REST-architected
>> networks, we don't.
>
>
> The Cocoon developers don't, but the script developer *does*. The
> Cocoon developers have implemented it. The fact that TCP is maintaining
> the connection or a continuation id doesn't much matter to me. The
> state management may be some smoke and mirrors, but it's an effective
> illusion.
>
>> Look at what sendPageAndWait() is supposed to do:
>>
>> 1) create the continuation object
>> 2) store it someplace
>> 3) get its id
>> 4) invoque the sitemap with the required URI
>> 5) pass the invocation parameters and the continuation id
>
>
> Okay, so I think I did understand the implementation.
>
>> Guess what? it doesn't wait at all!
>>
>> If it waited (say, stopping the execution of a java thread) we would
>> not be able to scale massively! (and this is the reason why nobody
>> with a grain of salt even proposed to stop thread execution on the
>> server side!)
>
>
> But there is the problem. Folks will have to know about continuations.
> The sitemap declarations that I have seen require the visualization of
> continuations and not wait states.
>
> The point of sendPageAndWait() is to mislead. It is meant to mislead in
> a benevolent manner, but mislead nonetheless. So instead of needing
> documentation on not explicitly saving state, you'll need documentation
> assuring that you aren't blocking threads per execution (if they are
> excluded from and ignorant of sitemap concerns) or documentation
> explaining why the function talks about waiting when they know
> continuations are used. Or, as is the case I detail below, has an
> unintended meaning. *
Oh, I see your point now. Hmmmm, hmmmm, hmmmm (cogitating mode)
> The issues that people have had in preventing all members of a team from
> the desire to read an understand the sitemap without regard to their
> role will come up again with flowmap. People want to know how it works.
> Good developers are many times pathological in their desire to know how
> something works before using it. Telling them that you are blocking or
> waiting is not going to satisfy that curiosity -- especially if they
> figure out that waiting is not even involved.
Hmmmm, hmmm, hmmm, ok, ok, what about something radically different like
getUserInputFromScreen(uri)
to replace sendPageAndWait()?
I think Miles has a very good point in underlying the fact that 'send'
and 'wait' might have semantical collision in respect of 'reinversion of
control'.
>> What I *love* about the concept of sendPageAndWait() is that its
>> semantics don't indicate what the method really does, but what the
>> user is expecting a 'simple' system to do.
>
>
> This does more than not indicate what the method really does. It
> misrepresents what the method really does. This is an important
> distinction I think.
Yes, I think I see it now.
>> Of course, when you call a database you expect to be waiting for the
>> resoult... but web programmers are used to all kind of dirty tricks to
>> be able to keep state and program FSM-like machineries.
>
>
> And web programmers are not used to control of the URI-space, processing
> pipelines, or any of the other aspects of Cocoon that are done contrary
> to just about any other framework out there today. Believe me, the
> sitemap took me *a lot* longer to grok than flow has. I am I think a
> fairly typical web developer, and I know very little about the internals
> of the flow engine except for some salient points: JavaScript with
> Rhino, continuations, and calls back to the client using
> sitemap-specified URLs and continuation IDs. I think you underestimate
> the ability of a web developer to get this.
No, but I want people who couldn't do web programming in the past to be
able to do it with cocoon.
> My personal experience was that Ovidiu announced a working JavaScript
> version and a summary of how it works. This was all that was necessary
> to get me excited. Was I excited because Cocoon had a new way of
> specifying logic? No. Was it the JavaScript? No. It was because you
> could specify your multi-page logic as a contiguous block and without
> worrying about state. This was the hook. This is why I believe other
> people will be hooked.
Oh, yeah, 100% agreement on that :)
> People who don't get that flow saves state aren't using flow. When you
> read the docs, when you look at the examples, and when you talk to
> coworkers, you will realize that you never explicily deal with state.
> I'm not disagreeing with your conclusions. I'm disagreeing with your
> premise that people will move to use flow *at all* if they don't know
> that it handles state and eliminates "all kind of dirty tricks."
>
>> So, this is the reason why I think it's cool to specify "AndWait",
>> because if you say "sendPage" people will think: ok, I have to save
>> the state myself.
>
>
> * That is not at all what I thought when I saw AndWait. AndWait holds
> no implication of saving state to me. Am I alone here? I don't see the
> association. Wait != SaveState to me at all! When I saw AndWait, I
> immediately assumed that you meant "wait for user input" and not "make
> the thread wait."
>
> Yes, we have all struggled with programming methods on the web. We are
> all too familiar with the series of web pages that accumulates hidden
> form field after hidden form field. There are developers out there who
> will still use that model even after flow is in a stable release. As a
> matter of fact, if people use Cocoon's flow, they were most likely aware
> of its state-saving virtues before they started. After all, if you are
> Joe Shmoe web developer, and you didn't know about state saving in flow,
> why would you ever think to use Cocoon's flow? Honestly.
Good point.
>> Several people proposed to have two different methods, one for sending
>> the page, one for saving the state, but it becomes problematic since
>> this separation can be abused (see my example above)
>
>
> I wholeheartedly agree.
>
>>> My fundamental question is this. How is blocking on user input any
>>> more special a case than blocking on database, network, filesystem,
>>> or any other data?
>>
>>
>> like I said, the intrinsic stateless nature of the web.
>
>
> ...which you are trying to hide and smooth away for the sake of the web
> developer. Do you see a difference in that database connections are
> likely to remain open during transactions while web users make no
> guarantees that page2 follows page1? I used to until the flow engine
> appeared.
:)
> From the point of view of the flow script developer, page2 does follow
> page1. The fact that the web client can hit the back button or jump to
> an unrelated page has no effect on the flow script developer's work. Due
> to the excellent work of the Cocoon developers, the flow script
> developer doesn't need to care anymore. He/she doesn't need to worry
> about clobbered cookies or expired POST data because of a back button
> anymore.
Bingo
Hey, dude, we are in violent agreement here :)
>>> They all can timeout. They all block/wait for data before returning.
>>
>>
>> Agreed, but the usual web developer doesn't think that way: he
>> *expects* to require to save state by himself/herself.
>
>
> I don't agree. I don't think they expect to save state *when using
> Cocoon's flow*. None of the examples explicitly save state. The
> documentation talks about removing the need for explicitly saving state.
> I worry that you underestimate the deductive ability of the average
> developer.
>
> Cocoon has pulled the rug out from under developers over and over again
> with great ideas that run contrary to web development norms. Compared
> to pipelines, the sitemap, actions, etc., flow seems a no-brainer to me.
> You seem to be obfuscating something that was clear to begin with --
> probably more clear than just about any other concept in Cocoon.
All right.
>>> The flow script developer is conceptually waiting for the function to
>>> return just like every other function call.
>>
>>
>> Yes, but you are not doing RPC, dude. it's not you calling somebody,
>> it's somebody calling you! Big conceptual difference.
>
>
> Yes. It is. But not a difference with which you must bludgeon
> developers over the head repeatedly. Do you honestly believe that if
> someone has written any code for the web at all, flow will suddenly make
> them forget that there's a client on the other end that must explicitly
> request page2 and something referring to their work with page1? In the
> unlikely event that it did, the development process would eliminate that
> thought in a heartbeat. It's a conceptual difference that doesn't
> require assistance from the function names to be driven home.
>
>> If you ask me a page, I give it to you with
>>
>> sendPageAndWait()
>>
>> and you go home, that continuation will simply expire, the execution
>> *will not* continue.
>>
>> This is a *very* different behavior from any blocking I/O paradigm.
>> And this is because it's not your code to be in control.
>>
>> In fact, they used the term 'reinversion of control' to describe the
>> architectural concepts behind continuation-based web logic.
>
>
> Here I think we may never agree.
never say never. You got me thinking about the fact that
"sendPage" has an intrinsic stateless meaning
and
"AndWait" has an intrinsic statefull meaning
but, together, they collide.
So, let's step back for a moment and think about it coherently: if you
had a command line application would you write
printLineAndWait("login:")
or
getInput("logic:")
I think we should focus the attention on the 'data getting back' not on
'our page going to the client'
besides, page is too related to publishing... gosh, we are so into
publishing we don't even notice anymore. Thank &deity; this list is
full of very skilled devil's advocates :)
> Yes, execution will not continue. Any
> resources allocated in the flow script will be garbage collected. I
> simply fail to see how this is any different *for the developer* to a
> servlet exception firing in a service function that throws. Before
> anyone jumps on me about that, I realize that you can't just put a
> try/catch block around sendPage(). This is where logic with
> continuations differs from Java and standard JavaScript. But again, I
> don't see why this item in particular is something any developer would
> be helped with AndWait(). If they don't get the web model or
> continuations, AndWait isn't going to make it any clearer. If they do
> get continuations, AndWait() is confusing.
Again, I think you have a point here.
[skip]
>> You definately have a good point, but I fear that web programmers are
>> so used to stateless environments where functions that return pages to
>> the client are not blocking (in fact, the act of sending a page frees
>> the thread!) that we need the extra working to make sure they see a
>> difference in what they are used to.
>
>
> Two possible scenarios:
>
> (1) They heard about this "flow thingy" and read the main documentation
> page. Here they see that state is automatically saved and logic is
> conceptually one contiguous block. If they don't get this after reading
> the page, they aren't going to use flow. Once again, what would be the
> point if they don't get it in the first place?
>
> (2) Flow is already in use at an organization. As soon as someone asks,
> "How or where should I save the state when I go to the next page?" alarm
> bells sound in coworkers' heads and they direct the person to the docs
> or just say, "No need to do it yourself, because it does it for you."
>
> Who uses anything unless they've researched at least at a minimum what
> it can do, how it compares to other models of web development, or your
> job makes you use it (presumably with someone who has done some basic
> research)? Who ever says, "I hear that ProjectX does web stuff. I
> think I'll start using it right now without doing any type of research
> or prep work"? (Or rather, who that you would actually ever want to
> work with... Any CTO that pushes technology without any reason or
> research is dooming a company anyway.)
>
> I do not see a third scenario where someone is using the flow engine but
> doesn't have someone else on hand who already gets it, hasn't understood
> why they want to use it, or what benefits it gives over standard web
> development models. If they don't have any of those three things, what
> would prompt them to even get to the point that AndWait() would even be
> looked at?
>
> However, this is of course my opinion, and I won't press the point
> further. If I've failed to sway you by now, I probably never will. I'll
> still use the flow engine either way. :)
You got me thinking that 'sendPage' (with and without 'AndWait') is
wrong semantics because it focus the attention on getting the page out,
instead of focusing on waiting until the data is received.
'waiting' in a continuation-wise sense, of course.
i think that if we focus our semantics on the 'way-back' from the client
instead that on the 'way-up' to it, we might gain further explicitness.
What do you people think?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Miles Elam <mi...@geekspeak.org>.
Stefano Mazzocchi wrote:
> No, because there is a state-preserving channel (a connection) between
> you and the database. On the web or any other REST-architected
> networks, we don't.
The Cocoon developers don't, but the script developer *does*. The
Cocoon developers have implemented it. The fact that TCP is maintaining
the connection or a continuation id doesn't much matter to me. The
state management may be some smoke and mirrors, but it's an effective
illusion.
> Look at what sendPageAndWait() is supposed to do:
>
> 1) create the continuation object
> 2) store it someplace
> 3) get its id
> 4) invoque the sitemap with the required URI
> 5) pass the invocation parameters and the continuation id
Okay, so I think I did understand the implementation.
> Guess what? it doesn't wait at all!
>
> If it waited (say, stopping the execution of a java thread) we would
> not be able to scale massively! (and this is the reason why nobody
> with a grain of salt even proposed to stop thread execution on the
> server side!)
But there is the problem. Folks will have to know about continuations.
The sitemap declarations that I have seen require the visualization of
continuations and not wait states.
The point of sendPageAndWait() is to mislead. It is meant to mislead in
a benevolent manner, but mislead nonetheless. So instead of needing
documentation on not explicitly saving state, you'll need documentation
assuring that you aren't blocking threads per execution (if they are
excluded from and ignorant of sitemap concerns) or documentation
explaining why the function talks about waiting when they know
continuations are used. Or, as is the case I detail below, has an
unintended meaning. *
The issues that people have had in preventing all members of a team from
the desire to read an understand the sitemap without regard to their
role will come up again with flowmap. People want to know how it works.
Good developers are many times pathological in their desire to know how
something works before using it. Telling them that you are blocking or
waiting is not going to satisfy that curiosity -- especially if they
figure out that waiting is not even involved.
> What I *love* about the concept of sendPageAndWait() is that its
> semantics don't indicate what the method really does, but what the
> user is expecting a 'simple' system to do.
This does more than not indicate what the method really does. It
misrepresents what the method really does. This is an important
distinction I think.
> Of course, when you call a database you expect to be waiting for the
> resoult... but web programmers are used to all kind of dirty tricks to
> be able to keep state and program FSM-like machineries.
And web programmers are not used to control of the URI-space, processing
pipelines, or any of the other aspects of Cocoon that are done contrary
to just about any other framework out there today. Believe me, the
sitemap took me *a lot* longer to grok than flow has. I am I think a
fairly typical web developer, and I know very little about the internals
of the flow engine except for some salient points: JavaScript with
Rhino, continuations, and calls back to the client using
sitemap-specified URLs and continuation IDs. I think you underestimate
the ability of a web developer to get this.
My personal experience was that Ovidiu announced a working JavaScript
version and a summary of how it works. This was all that was necessary
to get me excited. Was I excited because Cocoon had a new way of
specifying logic? No. Was it the JavaScript? No. It was because you
could specify your multi-page logic as a contiguous block and without
worrying about state. This was the hook. This is why I believe other
people will be hooked.
People who don't get that flow saves state aren't using flow. When you
read the docs, when you look at the examples, and when you talk to
coworkers, you will realize that you never explicily deal with state.
I'm not disagreeing with your conclusions. I'm disagreeing with your
premise that people will move to use flow *at all* if they don't know
that it handles state and eliminates "all kind of dirty tricks."
> So, this is the reason why I think it's cool to specify "AndWait",
> because if you say "sendPage" people will think: ok, I have to save
> the state myself.
* That is not at all what I thought when I saw AndWait. AndWait holds
no implication of saving state to me. Am I alone here? I don't see the
association. Wait != SaveState to me at all! When I saw AndWait, I
immediately assumed that you meant "wait for user input" and not "make
the thread wait."
Yes, we have all struggled with programming methods on the web. We are
all too familiar with the series of web pages that accumulates hidden
form field after hidden form field. There are developers out there who
will still use that model even after flow is in a stable release. As a
matter of fact, if people use Cocoon's flow, they were most likely aware
of its state-saving virtues before they started. After all, if you are
Joe Shmoe web developer, and you didn't know about state saving in flow,
why would you ever think to use Cocoon's flow? Honestly.
> Several people proposed to have two different methods, one for sending
> the page, one for saving the state, but it becomes problematic since
> this separation can be abused (see my example above)
I wholeheartedly agree.
>> My fundamental question is this. How is blocking on user input any
>> more special a case than blocking on database, network, filesystem,
>> or any other data?
>
> like I said, the intrinsic stateless nature of the web.
...which you are trying to hide and smooth away for the sake of the web
developer. Do you see a difference in that database connections are
likely to remain open during transactions while web users make no
guarantees that page2 follows page1? I used to until the flow engine
appeared.
From the point of view of the flow script developer, page2 does follow
page1. The fact that the web client can hit the back button or jump to
an unrelated page has no effect on the flow script developer's work.
Due to the excellent work of the Cocoon developers, the flow script
developer doesn't need to care anymore. He/she doesn't need to worry
about clobbered cookies or expired POST data because of a back button
anymore.
>> They all can timeout. They all block/wait for data before returning.
>
> Agreed, but the usual web developer doesn't think that way: he
> *expects* to require to save state by himself/herself.
I don't agree. I don't think they expect to save state *when using
Cocoon's flow*. None of the examples explicitly save state. The
documentation talks about removing the need for explicitly saving state.
I worry that you underestimate the deductive ability of the average
developer.
Cocoon has pulled the rug out from under developers over and over again
with great ideas that run contrary to web development norms. Compared
to pipelines, the sitemap, actions, etc., flow seems a no-brainer to me.
You seem to be obfuscating something that was clear to begin with --
probably more clear than just about any other concept in Cocoon.
>> The flow script developer is conceptually waiting for the function to
>> return just like every other function call.
>
> Yes, but you are not doing RPC, dude. it's not you calling somebody,
> it's somebody calling you! Big conceptual difference.
Yes. It is. But not a difference with which you must bludgeon
developers over the head repeatedly. Do you honestly believe that if
someone has written any code for the web at all, flow will suddenly make
them forget that there's a client on the other end that must explicitly
request page2 and something referring to their work with page1? In the
unlikely event that it did, the development process would eliminate that
thought in a heartbeat. It's a conceptual difference that doesn't
require assistance from the function names to be driven home.
> If you ask me a page, I give it to you with
>
> sendPageAndWait()
>
> and you go home, that continuation will simply expire, the execution
> *will not* continue.
>
> This is a *very* different behavior from any blocking I/O paradigm.
> And this is because it's not your code to be in control.
>
> In fact, they used the term 'reinversion of control' to describe the
> architectural concepts behind continuation-based web logic.
Here I think we may never agree. Yes, execution will not continue. Any
resources allocated in the flow script will be garbage collected. I
simply fail to see how this is any different *for the developer* to a
servlet exception firing in a service function that throws. Before
anyone jumps on me about that, I realize that you can't just put a
try/catch block around sendPage(). This is where logic with
continuations differs from Java and standard JavaScript. But again, I
don't see why this item in particular is something any developer would
be helped with AndWait(). If they don't get the web model or
continuations, AndWait isn't going to make it any clearer. If they do
get continuations, AndWait() is confusing.
> Maybe with this more information the picture changed somehow.
It has definitely helped me understand your point of view. I still
don't agree with it unfortunately.
> I think you are failing to see that there is a (admittedly subdle)
> difference between flow control (when you drive the I/O request) and
> reinverted flow control (when you 'fake' the fact that you drive the
> I/O request, but in fact, you are not).
On the contrary, I believe I did get that. I simply don't see why this
difference is relevant to practical scripting. If you're faking the
driver, why not commit? From the developer's point of view, what
fundamentally changes when they actively ponder reinverted flow control
versus a simple return from a function? Was the focus for this exercise
that they grok reinversion of control or that they have as simple as
possible model for advanced web development?
If there is no substanitive code difference (function names don't count
in this case), are there security issues or functionality issues
involved if the developer doesn't 'get' it? If so, flow has bigger
problems than a function name. If not, then let me give this analogy.
Why does a beginning Visual Basic Script developer on IIS+ASP need to
know how COM works (AddRef and Release, ApartmentThreads, DCOM) and all
of the issues involved that prompted the development of COM? The truth
is that they don't by and large. It isn't necessary to the model. And
as point of fact, because the implementation (actual or simulated) isn't
advertised, ASP development both on the client side and the server side
are simpler to handle. Sure if you're just starting out, you don't
realize that because of the underlying web model, you must send custom
headers and/or redirects before sending any content. But this doesn't
matter. So much work can be done and is done without this knowledge and
without explicit tag semantics saying in effect, "Start output of
content now." It is implied for the common case.
> You definately have a good point, but I fear that web programmers are
> so used to stateless environments where functions that return pages to
> the client are not blocking (in fact, the act of sending a page frees
> the thread!) that we need the extra working to make sure they see a
> difference in what they are used to.
Two possible scenarios:
(1) They heard about this "flow thingy" and read the main documentation
page. Here they see that state is automatically saved and logic is
conceptually one contiguous block. If they don't get this after reading
the page, they aren't going to use flow. Once again, what would be the
point if they don't get it in the first place?
(2) Flow is already in use at an organization. As soon as someone asks,
"How or where should I save the state when I go to the next page?" alarm
bells sound in coworkers' heads and they direct the person to the docs
or just say, "No need to do it yourself, because it does it for you."
Who uses anything unless they've researched at least at a minimum what
it can do, how it compares to other models of web development, or your
job makes you use it (presumably with someone who has done some basic
research)? Who ever says, "I hear that ProjectX does web stuff. I
think I'll start using it right now without doing any type of research
or prep work"? (Or rather, who that you would actually ever want to
work with... Any CTO that pushes technology without any reason or
research is dooming a company anyway.)
I do not see a third scenario where someone is using the flow engine but
doesn't have someone else on hand who already gets it, hasn't understood
why they want to use it, or what benefits it gives over standard web
development models. If they don't have any of those three things, what
would prompt them to even get to the point that AndWait() would even be
looked at?
However, this is of course my opinion, and I won't press the point
further. If I've failed to sway you by now, I probably never will.
I'll still use the flow engine either way. :)
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Miles Elam wrote:
> Stefano Mazzocchi wrote:
>
>> Hmmm, what happens if I do
>>
>> sendPage("foo")
>> getAnswerFor("bar")
>>
>> ???
>>
>> I think that sendPageAndWait() *is* atomic once you get it. Separating
>> the two doesn't sound like SoC anymore if you can mess up like above,
>> it becomes FoC (fragmentation of concerns) which is bad
>
>
> Forgive my interruption, but what does atomicity have to do with this at
> all? Unless I missed something fundamental to the flowscript examples I
> have seen, they are all single-threaded paths of execution. Atomicity
> in the database sense is only difficult when you have multiple clients
> working on the same dataset. If there is only one client, even flat
> file datastore access is atomic. Atomicity in programmatic logic is
> only necessary when you have multiple threads/processes accessing a
> common resource.
>
> sendPageAndWait() still sounds like too much implementation detail to
> me. Do you execute executeQueryAndWait() to a database connection?
No, because there is a state-preserving channel (a connection) between
you and the database. On the web or any other REST-architected networks,
we don't.
> The
> function still blocks until the database has enough time and resources
> to respond. sendPage() (or just about every other function name method
> thus far) strikes me as an intrinsically atomic construct by virtue of
> the fact that it is executed in a single solitary path of execution.
I think I abused the term 'atomic' for this.
Look at what sendPageAndWait() is supposed to do:
1) create the continuation object
2) store it someplace
3) get its id
4) invoque the sitemap with the required URI
5) pass the invocation parameters and the continuation id
Guess what? it doesn't wait at all!
If it waited (say, stopping the execution of a java thread) we would not
be able to scale massively! (and this is the reason why nobody with a
grain of salt even proposed to stop thread execution on the server side!)
What I *love* about the concept of sendPageAndWait() is that its
semantics don't indicate what the method really does, but what the user
is expecting a 'simple' system to do.
Of course, when you call a database you expect to be waiting for the
resoult... but web programmers are used to all kind of dirty tricks to
be able to keep state and program FSM-like machineries.
So, this is the reason why I think it's cool to specify "AndWait",
because if you say "sendPage" people will think: ok, I have to save the
state myself.
So, what I called "atomicity" is the fact that two operations:
1) sending the page
2) keeping the state
were done at the same time, without having the user to think about it
explicitly.
Several people proposed to have two different methods, one for sending
the page, one for saving the state, but it becomes problematic since
this separation can be abused (see my example above)
> The only problem I see with getAnswerFor() is that a page may not return
> information other than a continuation id (eg. license agreements,
> general status pages detailing your information up to a certain point,
> etc.). However, even with getAnswerFor() and sendPage(), I doubt it
> would be too terrible to simply set a flag whenever sendPage() is called
> so that if getAnswerFor() is called after it, it fires an exception
> alerting the developer that he/she can't do that.
>
> On a similar note, what is the use case for calling sendPage() (without
> the wait) and then sendPageAndWait() later? I think I missed that part
> of the discussion in the archives. Once you send a response in a web
> model, you can't send another with the expectation that the client is
> still listening.
>
> This is the reason I proposed sendLastPage(). Semantically it implies
> that no other requests will be sent from the client regard this extended
> conversation; The give and take is over.
>
> So:
>
> sendPage(foo1);
> sendPage(foo2);
> sendPage(foo3);
> ...
> sendPage(fooN);
> sendLastPage(finishfoo);
>
> Conceptually, all of them block until the sendLastPage() call.
> Semantically -- at least in my mind -- it makes no sense to send a page
> after the last (non-blocking) page. Does it make sense to send two last
> pages? No. Does it make sense to send a page after the last one? No.
> Conceptually *very* simple for the end developer.
>
> My fundamental question is this. How is blocking on user input any more
> special a case than blocking on database, network, filesystem, or any
> other data?
like I said, the intrinsic stateless nature of the web.
> Granted, the point of the code is usually for the benefit
> of the user, but in this case, the focus is on the script developer.
> From the script developer's point of view, how are database
> connections, network connections, filesystem accesses, or user form
> inputs any different from one another? They all can timeout. They all
> block/wait for data before returning.
Agreed, but the usual web developer doesn't think that way: he *expects*
to require to save state by himself/herself.
> The flow script developer is
> conceptually waiting for the function to return just like every other
> function call.
Yes, but you are not doing RPC, dude. it's not you calling somebody,
it's somebody calling you! Big conceptual difference.
If the user doesn't respond, a timeout occurs that
> interrupts execution just like when a database becomes unavailable and
> the exception breaks the flow of execution.
Wrong.
If you ask me a page, I give it to you with
sendPageAndWait()
and you go home, that continuation will simply expire, the execution
*will not* continue.
This is a *very* different behavior from any blocking I/O paradigm. And
this is because it's not your code to be in control.
In fact, they used the term 'reinversion of control' to describe the
architectural concepts behind continuation-based web logic.
> I don't mean to butt in when I haven't contributed to flow, but as I
> will be a user of this API, obscure function semantics aren't going to
> make my life easier when I teach others how to use it.
Maybe with this more information the picture changed somehow.
> If I have a fundamental misunderstanding of the issues involved, please
> let me know on or off the list.
I think you are failing to see that there is a (admittedly subdle)
difference between flow control (when you drive the I/O request) and
reinverted flow control (when you 'fake' the fact that you drive the I/O
request, but in fact, you are not).
> A URL or book reference will do. But I
> fail to see the logic in enforcing wait/block denotation to the function
> name when connotation is already there in a function call.
You definately have a good point, but I fear that web programmers are so
used to stateless environments where functions that return pages to the
client are not blocking (in fact, the act of sending a page frees the
thread!) that we need the extra working to make sure they see a
difference in what they are used to.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Miles Elam <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> Hmmm, what happens if I do
>
> sendPage("foo")
> getAnswerFor("bar")
>
> ???
>
> I think that sendPageAndWait() *is* atomic once you get it. Separating
> the two doesn't sound like SoC anymore if you can mess up like above,
> it becomes FoC (fragmentation of concerns) which is bad
Forgive my interruption, but what does atomicity have to do with this at
all? Unless I missed something fundamental to the flowscript examples I
have seen, they are all single-threaded paths of execution. Atomicity
in the database sense is only difficult when you have multiple clients
working on the same dataset. If there is only one client, even flat
file datastore access is atomic. Atomicity in programmatic logic is
only necessary when you have multiple threads/processes accessing a
common resource.
sendPageAndWait() still sounds like too much implementation detail to
me. Do you execute executeQueryAndWait() to a database connection? The
function still blocks until the database has enough time and resources
to respond. sendPage() (or just about every other function name method
thus far) strikes me as an intrinsically atomic construct by virtue of
the fact that it is executed in a single solitary path of execution.
The only problem I see with getAnswerFor() is that a page may not return
information other than a continuation id (eg. license agreements,
general status pages detailing your information up to a certain point,
etc.). However, even with getAnswerFor() and sendPage(), I doubt it
would be too terrible to simply set a flag whenever sendPage() is called
so that if getAnswerFor() is called after it, it fires an exception
alerting the developer that he/she can't do that.
On a similar note, what is the use case for calling sendPage() (without
the wait) and then sendPageAndWait() later? I think I missed that part
of the discussion in the archives. Once you send a response in a web
model, you can't send another with the expectation that the client is
still listening.
This is the reason I proposed sendLastPage(). Semantically it implies
that no other requests will be sent from the client regard this extended
conversation; The give and take is over.
So:
sendPage(foo1);
sendPage(foo2);
sendPage(foo3);
...
sendPage(fooN);
sendLastPage(finishfoo);
Conceptually, all of them block until the sendLastPage() call.
Semantically -- at least in my mind -- it makes no sense to send a page
after the last (non-blocking) page. Does it make sense to send two last
pages? No. Does it make sense to send a page after the last one? No.
Conceptually *very* simple for the end developer.
My fundamental question is this. How is blocking on user input any more
special a case than blocking on database, network, filesystem, or any
other data? Granted, the point of the code is usually for the benefit
of the user, but in this case, the focus is on the script developer.
From the script developer's point of view, how are database
connections, network connections, filesystem accesses, or user form
inputs any different from one another? They all can timeout. They all
block/wait for data before returning. The flow script developer is
conceptually waiting for the function to return just like every other
function call. If the user doesn't respond, a timeout occurs that
interrupts execution just like when a database becomes unavailable and
the exception breaks the flow of execution.
I don't mean to butt in when I haven't contributed to flow, but as I
will be a user of this API, obscure function semantics aren't going to
make my life easier when I teach others how to use it.
If I have a fundamental misunderstanding of the issues involved, please
let me know on or off the list. A URL or book reference will do. But I
fail to see the logic in enforcing wait/block denotation to the function
name when connotation is already there in a function call.
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Marc Portier <mp...@outerthought.org>.
Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
>
>> On Fri, 6 Dec 2002, Marc Portier wrote:
>>
>>
>>>
>>> Christian Haul wrote:
>>>
>>>> On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
>>>>
>>>>
>>>>> Giacomo, Sylvain,
>>>>>
>>>>> I see my remark wasn't that stupid after all (taking as an
>>>>> argument the fact the statistic unlikeliness of having exact
>>>>> equal idiots) Sorry, for not earlier reading deeper down the
>>>>> thread though...
>>>>>
>>>>> only I'm not ready to give in yet...
>>>>>
>>>>> is making a continuation really atomicly linked to sending a
>>>>> page? Your argumentation makes me see that:
>>>>> Rather then 2 there are 3 concerns covered in the sendPageAnd...
>>>>> I guess it's more like
>>>>> makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
>>>>> :-)
>>>>
>>>>
>>>>
>>>> The problem is that you need to have something to place on the page
>>>> that links to the continuation id. Thus you need to have your
>>>> continuation before sending the page. Hence suspending and sending is
>>>> one atomic operation.
>>>>
>>>> Chris.
>>>
>>>
>>> Now I see it: when the page is sent the links are available to be
>>> clicked upon and thus the 'state' should be there.
>>>
>>> I only considered the creation part ATM (and there I argumented
>>> that for creating the URI-links you don't need to save the state
>>> yet)
>>>
>>> Think I got it now, so we are back to the straightforward naming
>>> discussion... thinking back of my highschool-basic-time this
>>> kinda boils down to finding the equivalent of
>>>
>>> 0 CLS
>>> 10 PRINT "This is only out:"
>>> 20 INPUT "This prompt asks you to enter something:" , answer
>>>
>>> which would make me advocate
>>>
>>> for the output only:
>>> sendPage("name-o-page") or even
>>> printPage(...) or
>>> echoPage(...)
>>>
>>> for the input kind of page
>>> getFormInput("name-o-form") or
>>> getFormReply(...)
>>
>>
>>
>> And thus we are back to my lastly proposed method names:
>>
>> sendPage( page ) // without waiting
>>
>> getAnswerFor( page )
>> or
>> getReplyFor( page )
>
>
> Hmmm, what happens if I do
>
> sendPage("foo")
> getAnswerFor("bar")
>
> ???
>
> I think that sendPageAndWait() *is* atomic once you get it. Separating
> the two doesn't sound like SoC anymore if you can mess up like above, it
> becomes FoC (fragmentation of concerns) which is bad
>
good argument, but do you only solve this with naming?
sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoes("bar");
or
sendLastPage();
sendNextPage(); //sorry, wasn't the last after all?
would offer you the same dillema
as would even:
sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoesntWait("bar");
a discussion we also had earlier in the thread...
and which you pointed out so clearly with the remark that *this
all* keeps on being a servlet generating a simple response (not a
screen we can add a line to)
The question Michael posed keeps on being not solved:
> On 06.Dec.2002 -- 11:09 AM, Michael Melhem wrote:
>>> On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:
>>>> > "Finish" what? The problem with that is that you could still do things
>>>> > after the page was sent back to the client. Advanced users might want
>>>> > to use this fact to do all sorts of nasty things.
>>> Interesting, didnt think of that. So does this mean you can send
>>> multiple pages back to the client without client intereaction.. ?
Anyone?
For me, as for Miles Elam:
> I don't mean to butt in when I haven't contributed to flow, but as I will be a user of this API, obscure function semantics aren't going to make my life easier when I teach others how to use it.
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Giacomo Pati <gi...@apache.org>.
On Sat, 7 Dec 2002, Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
> > On Fri, 6 Dec 2002, Marc Portier wrote:
> >
> >
> >>
> >>Christian Haul wrote:
> >>
> >>>On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
> >>>
> >>>
> >>>>Giacomo, Sylvain,
> >>>>
> >>>>I see my remark wasn't that stupid after all (taking as an
> >>>>argument the fact the statistic unlikeliness of having exact
> >>>>equal idiots) Sorry, for not earlier reading deeper down the
> >>>>thread though...
> >>>>
> >>>>only I'm not ready to give in yet...
> >>>>
> >>>>is making a continuation really atomicly linked to sending a
> >>>>page? Your argumentation makes me see that:
> >>>>Rather then 2 there are 3 concerns covered in the sendPageAnd...
> >>>>I guess it's more like
> >>>>makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
> >>>>:-)
> >>>
> >>>
> >>>The problem is that you need to have something to place on the page
> >>>that links to the continuation id. Thus you need to have your
> >>>continuation before sending the page. Hence suspending and sending is
> >>>one atomic operation.
> >>>
> >>> Chris.
> >>
> >>Now I see it: when the page is sent the links are available to be
> >>clicked upon and thus the 'state' should be there.
> >>
> >>I only considered the creation part ATM (and there I argumented
> >>that for creating the URI-links you don't need to save the state
> >>yet)
> >>
> >>Think I got it now, so we are back to the straightforward naming
> >>discussion... thinking back of my highschool-basic-time this
> >>kinda boils down to finding the equivalent of
> >>
> >> 0 CLS
> >>10 PRINT "This is only out:"
> >>20 INPUT "This prompt asks you to enter something:" , answer
> >>
> >>which would make me advocate
> >>
> >>for the output only:
> >> sendPage("name-o-page") or even
> >> printPage(...) or
> >> echoPage(...)
> >>
> >>for the input kind of page
> >> getFormInput("name-o-form") or
> >> getFormReply(...)
> >
> >
> > And thus we are back to my lastly proposed method names:
> >
> > sendPage( page ) // without waiting
> >
> > getAnswerFor( page )
> > or
> > getReplyFor( page )
>
> Hmmm, what happens if I do
>
> sendPage("foo")
> getAnswerFor("bar")
The same as if you do
sendPageWithoutWait("foo")
sendPageAndWait("bar")
>
> ???
>
> I think that sendPageAndWait() *is* atomic once you get it. Separating
> the two doesn't sound like SoC anymore if you can mess up like above, it
> becomes FoC (fragmentation of concerns) which is bad
I've already seen (thanks to Sylvain IIRC) that we cannot separate sending
and waiting. My suggetion was for the names of the respective functions.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> On Fri, 6 Dec 2002, Marc Portier wrote:
>
>
>>
>>Christian Haul wrote:
>>
>>>On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
>>>
>>>
>>>>Giacomo, Sylvain,
>>>>
>>>>I see my remark wasn't that stupid after all (taking as an
>>>>argument the fact the statistic unlikeliness of having exact
>>>>equal idiots) Sorry, for not earlier reading deeper down the
>>>>thread though...
>>>>
>>>>only I'm not ready to give in yet...
>>>>
>>>>is making a continuation really atomicly linked to sending a
>>>>page? Your argumentation makes me see that:
>>>>Rather then 2 there are 3 concerns covered in the sendPageAnd...
>>>>I guess it's more like
>>>>makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
>>>>:-)
>>>
>>>
>>>The problem is that you need to have something to place on the page
>>>that links to the continuation id. Thus you need to have your
>>>continuation before sending the page. Hence suspending and sending is
>>>one atomic operation.
>>>
>>> Chris.
>>
>>Now I see it: when the page is sent the links are available to be
>>clicked upon and thus the 'state' should be there.
>>
>>I only considered the creation part ATM (and there I argumented
>>that for creating the URI-links you don't need to save the state
>>yet)
>>
>>Think I got it now, so we are back to the straightforward naming
>>discussion... thinking back of my highschool-basic-time this
>>kinda boils down to finding the equivalent of
>>
>> 0 CLS
>>10 PRINT "This is only out:"
>>20 INPUT "This prompt asks you to enter something:" , answer
>>
>>which would make me advocate
>>
>>for the output only:
>> sendPage("name-o-page") or even
>> printPage(...) or
>> echoPage(...)
>>
>>for the input kind of page
>> getFormInput("name-o-form") or
>> getFormReply(...)
>
>
> And thus we are back to my lastly proposed method names:
>
> sendPage( page ) // without waiting
>
> getAnswerFor( page )
> or
> getReplyFor( page )
Hmmm, what happens if I do
sendPage("foo")
getAnswerFor("bar")
???
I think that sendPageAndWait() *is* atomic once you get it. Separating
the two doesn't sound like SoC anymore if you can mess up like above, it
becomes FoC (fragmentation of concerns) which is bad
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 6 Dec 2002, Marc Portier wrote:
>
>
> Christian Haul wrote:
> > On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
> >
> >>Giacomo, Sylvain,
> >>
> >>I see my remark wasn't that stupid after all (taking as an
> >>argument the fact the statistic unlikeliness of having exact
> >>equal idiots) Sorry, for not earlier reading deeper down the
> >>thread though...
> >>
> >>only I'm not ready to give in yet...
> >>
> >>is making a continuation really atomicly linked to sending a
> >>page? Your argumentation makes me see that:
> >>Rather then 2 there are 3 concerns covered in the sendPageAnd...
> >>I guess it's more like
> >>makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
> >>:-)
> >
> >
> > The problem is that you need to have something to place on the page
> > that links to the continuation id. Thus you need to have your
> > continuation before sending the page. Hence suspending and sending is
> > one atomic operation.
> >
> > Chris.
>
> Now I see it: when the page is sent the links are available to be
> clicked upon and thus the 'state' should be there.
>
> I only considered the creation part ATM (and there I argumented
> that for creating the URI-links you don't need to save the state
> yet)
>
> Think I got it now, so we are back to the straightforward naming
> discussion... thinking back of my highschool-basic-time this
> kinda boils down to finding the equivalent of
>
> 0 CLS
> 10 PRINT "This is only out:"
> 20 INPUT "This prompt asks you to enter something:" , answer
>
> which would make me advocate
>
> for the output only:
> sendPage("name-o-page") or even
> printPage(...) or
> echoPage(...)
>
> for the input kind of page
> getFormInput("name-o-form") or
> getFormReply(...)
And thus we are back to my lastly proposed method names:
sendPage( page ) // without waiting
getAnswerFor( page )
or
getReplyFor( page )
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Marc Portier <mp...@outerthought.org>.
Christian Haul wrote:
> On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
>
>>Giacomo, Sylvain,
>>
>>I see my remark wasn't that stupid after all (taking as an
>>argument the fact the statistic unlikeliness of having exact
>>equal idiots) Sorry, for not earlier reading deeper down the
>>thread though...
>>
>>only I'm not ready to give in yet...
>>
>>is making a continuation really atomicly linked to sending a
>>page? Your argumentation makes me see that:
>>Rather then 2 there are 3 concerns covered in the sendPageAnd...
>>I guess it's more like
>>makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
>>:-)
>
>
> The problem is that you need to have something to place on the page
> that links to the continuation id. Thus you need to have your
> continuation before sending the page. Hence suspending and sending is
> one atomic operation.
>
> Chris.
Now I see it: when the page is sent the links are available to be
clicked upon and thus the 'state' should be there.
I only considered the creation part ATM (and there I argumented
that for creating the URI-links you don't need to save the state
yet)
Think I got it now, so we are back to the straightforward naming
discussion... thinking back of my highschool-basic-time this
kinda boils down to finding the equivalent of
0 CLS
10 PRINT "This is only out:"
20 INPUT "This prompt asks you to enter something:" , answer
which would make me advocate
for the output only:
sendPage("name-o-page") or even
printPage(...) or
echoPage(...)
for the input kind of page
getFormInput("name-o-form") or
getFormReply(...)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
Chris,
On Friday, Dec 6, 2002, at 07:31 US/Pacific, Christian Haul wrote:
> On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
>> Giacomo, Sylvain,
>>
>> I see my remark wasn't that stupid after all (taking as an
>> argument the fact the statistic unlikeliness of having exact
>> equal idiots) Sorry, for not earlier reading deeper down the
>> thread though...
>>
>> only I'm not ready to give in yet...
>>
>> is making a continuation really atomicly linked to sending a
>> page? Your argumentation makes me see that:
>> Rather then 2 there are 3 concerns covered in the sendPageAnd...
>> I guess it's more like
>> makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
>> :-)
>
> The problem is that you need to have something to place on the page
> that links to the continuation id. Thus you need to have your
> continuation before sending the page. Hence suspending and sending is
> one atomic operation.
Please see my response to Marc. You can create the continuation id
first, pass it to the client and only then create the continuation
object and associate it with the id.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 06.Dec.2002 -- 04:07 PM, Marc Portier wrote:
> Giacomo, Sylvain,
>
> I see my remark wasn't that stupid after all (taking as an
> argument the fact the statistic unlikeliness of having exact
> equal idiots) Sorry, for not earlier reading deeper down the
> thread though...
>
> only I'm not ready to give in yet...
>
> is making a continuation really atomicly linked to sending a
> page? Your argumentation makes me see that:
> Rather then 2 there are 3 concerns covered in the sendPageAnd...
> I guess it's more like
> makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
> :-)
The problem is that you need to have something to place on the page
that links to the continuation id. Thus you need to have your
continuation before sending the page. Hence suspending and sending is
one atomic operation.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
Hi Marc,
Good to see you delving deep into this stuff!
On Friday, Dec 6, 2002, at 07:07 US/Pacific, Marc Portier wrote:
> Giacomo, Sylvain,
>
> I see my remark wasn't that stupid after all (taking as an argument
> the fact the statistic unlikeliness of having exact equal idiots)
> Sorry, for not earlier reading deeper down the thread though...
>
> only I'm not ready to give in yet...
>
> is making a continuation really atomicly linked to sending a page?
> Your argumentation makes me see that:
> Rather then 2 there are 3 concerns covered in the sendPageAnd...
> I guess it's more like
> makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
> :-)
>
>
>
> coming back on the expressed idea of splitting the methods up, it
> could make sense to thus split it up in 3 steps.
>
> //1.
> var continuation = makeNewContinuation();
> // creates a URI in fact to talk about this continuation
>
> //2.
> sendPage("page from sitemap", continuation);
> // allowing sendPage to insert the required links
>
> ...
> //do other stuff if you like, other sendPages (see previous remark)
> should probably fail
>
> //3.
> waitForContinuation(continuation); // saves the current state of
> script vars and position into the ref
>
>
> making it atomic makes it probably more idiot-proof, but access to the
> actual continuation object seems to open up a number of other
> interesting things:
Yes, what you describe makes perfect sense. To avoid confusion though,
the makeNewContinuation should be called makeNewContinuationId(),
because it's not the function that creates the continuation, it only
creates a continuation Id to passed by sendPage() in the generated
response sent back to the client.
The idea is that you create the continuation id first, pass it in the
View to be sent to the client, and only then you create the
continuation object and associate it with the continuation id.
Perfectly valid scenario.
The actual continuation has to be created by the waitForContinuation(),
which should take the continuation id, create the continuation object,
and associates them in the global continuations hash table. This
function will essentially do what _sendPage() does today in system.js.
> >> reuse explicitely one of the previous continuations
> suppose submission of form "start-sequence" triggers this script:
>
> var c = makeNewContinuation();
> sendPage("p1", c);
> waitForContinuation(c);
> sendPage("p2", c);
> waitForContinuation(c);
> sendPage("end-result"); // no continuation ref!
>
> this would allow the user to follow this path:
> start-sequence > {submit} > p1 > {submit} > p2 > {submit} > end-result
>
> but also to proceed with {back|back} > p1 > {submit} > end-result
>
> offering something I would call the
> 'should-only-pass-once-step-in-the-chain' (p2 in this example)
> specially for larger wizard-like flows it could be nice to be able to
> 'skip' the steps that were already taken
>
> (the real life example that would say that p2 could not just be up
> front of p1 in this case is missing ATM :-( )
Again, 'c' in the above example is not really the continuation, but the
continuation id as I described above.
Yes, this makes perfect sense and is a good use case. The beauty of the
continuations based control flow system is that even if the raw Cocoon
doesn't support this kind of functionality, you as developer can
implement it very easily with very few lines of code. Just tell me how
much code you need to write this without control flow.
> it also seems to be a less memory-hungry way to implement something of
> the sort:
>
> var result = startLengthyOperationAsync();
> var c = makeNewContinuation();
> while (!result.isReady()) {
> sendPage("GoingStrongPleaseCheckBack.html", c);
> waitForContinuation(c);
> }
> sendPage("showResult"); // no continuation argument!
That's perfectly correct! You can do all sorts of nasty things, since
you have complete control over the system. Again 'c' here should be a
continuation id, not the true continuation.
> all of this probably makes it harder to make it resiliant to script
> errors of course... what if
>
> var c1 = makeNewContinuation();
> sendPage("p1", c1);
> waitForContinuation(c1);
> var c2 = makeNewContinuation();
> sendPage("p2", c2);
> waitForContinuation(c1);
Which is indeed a big problem. That's why the default API is sort of
idiot-proof and doesn't allow you to do this type of things. Advanced
users could easily implement whatever they want.
Regards,
Ovidiu
> Sylvain Wallez wrote:
>> Giacomo Pati wrote:
>>> On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
>>>
>>>
>>>> I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
>>>> that much, but it's true that 'sendPage' contains less semantic
>>>> meaning
>>>> than 'sendPageAndWait' and therefore might become a little
>>>> confusing at
>>>> first. It's a little bit semantically unbalanced and this doesn't
>>>> reflect in their functional operation.
>>>>
>>>> So, let's see, that method is supposed to 'send a page' to the
>>>> client
>>>> but is not going to wait for the client to come back and continue.
>>>> So,
>>>> the real name would be something like
>>>>
>>>> - sendPageAndDontWait
>>>>
>>>> but that sucks.
>>>>
>>>> - sendPageAndReturn
>>>>
>>>> is nice but only if you understand that the flow layer takes control
>>>> over the sitemap and that 'return' means that you are returning from
>>>> procedural continuation-based control (the flowscript) to
>>>> declerative
>>>> request driven control (the sitemap)
>>>>
>>>> So it does have perfect sense for us, but I'm not sure it does for
>>>> somebody that looks at the flowscript for the first time.
>>>>
>>>> But I can't come up with anything better because
>>>>
>>>> - sendPageAndExit
>>>>
>>>> might be even worse (people might think Cocoon might stop!)
>>>>
>>>> Any idea?
>>>>
>>>
>>>
>>> As you said above the function does two things:
>>>
>>> 1. send a page
>>> 2. does not wait
>>>
>>> So, how about splitting it into two function:
>>>
>>> - sendPage
>>> - getAnswer
>>>
>> Semantically speaking, this is a _really good_ idea, but... it
>> unfortunately cannot be implemented that way :(
>> The reason is that suspending the flow (with getAnswer) involves
>> creating a continuation object, and that the page that is displayed
>> (with sendPage) must know the ID of that continuation in order to put
>> it in page links or form actions that will later on resume that
>> continuation.
>> So you would need in "sendPage" an information that is given later by
>> "getAnswer". Chicken and egg problem which requires merging into a
>> single function the operations of sending a page and waiting (or not)
>> for the user's input.
>> See o/a/c.components/flow/javascript/system.js for more details.
>> Too bad...
>> Sylvain
>
> --
> Marc Portier http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> mpo@outerthought.org mpo@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Marc Portier <mp...@outerthought.org>.
Giacomo, Sylvain,
I see my remark wasn't that stupid after all (taking as an
argument the fact the statistic unlikeliness of having exact
equal idiots) Sorry, for not earlier reading deeper down the
thread though...
only I'm not ready to give in yet...
is making a continuation really atomicly linked to sending a
page? Your argumentation makes me see that:
Rather then 2 there are 3 concerns covered in the sendPageAnd...
I guess it's more like
makeAContinuationRef_And_UseItToSendPage_And_SafeStateForNextRequest
:-)
coming back on the expressed idea of splitting the methods up, it
could make sense to thus split it up in 3 steps.
//1.
var continuation = makeNewContinuation();
// creates a URI in fact to talk about this continuation
//2.
sendPage("page from sitemap", continuation);
// allowing sendPage to insert the required links
...
//do other stuff if you like, other sendPages (see previous
remark) should probably fail
//3.
waitForContinuation(continuation); // saves the current state of
script vars and position into the ref
making it atomic makes it probably more idiot-proof, but access
to the actual continuation object seems to open up a number of
other interesting things:
>> reuse explicitely one of the previous continuations
suppose submission of form "start-sequence" triggers this script:
var c = makeNewContinuation();
sendPage("p1", c);
waitForContinuation(c);
sendPage("p2", c);
waitForContinuation(c);
sendPage("end-result"); // no continuation ref!
this would allow the user to follow this path:
start-sequence > {submit} > p1 > {submit} > p2 > {submit} >
end-result
but also to proceed with {back|back} > p1 > {submit} > end-result
offering something I would call the
'should-only-pass-once-step-in-the-chain' (p2 in this example)
specially for larger wizard-like flows it could be nice to be
able to 'skip' the steps that were already taken
(the real life example that would say that p2 could not just be
up front of p1 in this case is missing ATM :-( )
it also seems to be a less memory-hungry way to implement
something of the sort:
var result = startLengthyOperationAsync();
var c = makeNewContinuation();
while (!result.isReady()) {
sendPage("GoingStrongPleaseCheckBack.html", c);
waitForContinuation(c);
}
sendPage("showResult"); // no continuation argument!
all of this probably makes it harder to make it resiliant to
script errors of course... what if
var c1 = makeNewContinuation();
sendPage("p1", c1);
waitForContinuation(c1);
var c2 = makeNewContinuation();
sendPage("p2", c2);
waitForContinuation(c1);
regards,
-marc=
Sylvain Wallez wrote:
> Giacomo Pati wrote:
>
>> On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
>>
>>
>>
>>> I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
>>> that much, but it's true that 'sendPage' contains less semantic meaning
>>> than 'sendPageAndWait' and therefore might become a little confusing at
>>> first. It's a little bit semantically unbalanced and this doesn't
>>> reflect in their functional operation.
>>>
>>> So, let's see, that method is supposed to 'send a page' to the client
>>> but is not going to wait for the client to come back and continue. So,
>>> the real name would be something like
>>>
>>> - sendPageAndDontWait
>>>
>>> but that sucks.
>>>
>>> - sendPageAndReturn
>>>
>>> is nice but only if you understand that the flow layer takes control
>>> over the sitemap and that 'return' means that you are returning from
>>> procedural continuation-based control (the flowscript) to declerative
>>> request driven control (the sitemap)
>>>
>>> So it does have perfect sense for us, but I'm not sure it does for
>>> somebody that looks at the flowscript for the first time.
>>>
>>> But I can't come up with anything better because
>>>
>>> - sendPageAndExit
>>>
>>> might be even worse (people might think Cocoon might stop!)
>>>
>>> Any idea?
>>>
>>
>>
>> As you said above the function does two things:
>>
>> 1. send a page
>> 2. does not wait
>>
>> So, how about splitting it into two function:
>>
>> - sendPage
>> - getAnswer
>>
>>
>
> Semantically speaking, this is a _really good_ idea, but... it
> unfortunately cannot be implemented that way :(
>
> The reason is that suspending the flow (with getAnswer) involves
> creating a continuation object, and that the page that is displayed
> (with sendPage) must know the ID of that continuation in order to put it
> in page links or form actions that will later on resume that continuation.
>
> So you would need in "sendPage" an information that is given later by
> "getAnswer". Chicken and egg problem which requires merging into a
> single function the operations of sending a page and waiting (or not)
> for the user's input.
>
> See o/a/c.components/flow/javascript/system.js for more details.
>
> Too bad...
>
> Sylvain
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Giacomo Pati <gi...@apache.org>.
On Thu, 5 Dec 2002, Sylvain Wallez wrote:
> Giacomo Pati wrote:
>
> >On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
> >
> >
> >
> >>I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
> >>that much, but it's true that 'sendPage' contains less semantic meaning
> >>than 'sendPageAndWait' and therefore might become a little confusing at
> >>first. It's a little bit semantically unbalanced and this doesn't
> >>reflect in their functional operation.
> >>
> >>So, let's see, that method is supposed to 'send a page' to the client
> >>but is not going to wait for the client to come back and continue. So,
> >>the real name would be something like
> >>
> >> - sendPageAndDontWait
> >>
> >>but that sucks.
> >>
> >> - sendPageAndReturn
> >>
> >>is nice but only if you understand that the flow layer takes control
> >>over the sitemap and that 'return' means that you are returning from
> >>procedural continuation-based control (the flowscript) to declerative
> >>request driven control (the sitemap)
> >>
> >>So it does have perfect sense for us, but I'm not sure it does for
> >>somebody that looks at the flowscript for the first time.
> >>
> >>But I can't come up with anything better because
> >>
> >> - sendPageAndExit
> >>
> >>might be even worse (people might think Cocoon might stop!)
> >>
> >>Any idea?
> >>
> >>
> >
> >As you said above the function does two things:
> >
> > 1. send a page
> > 2. does not wait
> >
> >So, how about splitting it into two function:
> >
> > - sendPage
> > - getAnswer
> >
> >
>
> Semantically speaking, this is a _really good_ idea, but... it
> unfortunately cannot be implemented that way :(
>
> The reason is that suspending the flow (with getAnswer) involves
> creating a continuation object, and that the page that is displayed
> (with sendPage) must know the ID of that continuation in order to put it
> in page links or form actions that will later on resume that continuation.
Ok, I'm not into the code so let me think...
How about
sendPage (doing it without waiting for an answer)
and
getAnswerFor( page ) (doing a wait)
getReplyFor( page )
Giacomo
>
> So you would need in "sendPage" an information that is given later by
> "getAnswer". Chicken and egg problem which requires merging into a
> single function the operations of sending a page and waiting (or not)
> for the user's input.
>
> See o/a/c.components/flow/javascript/system.js for more details.
>
> Too bad...
>
> Sylvain
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Giacomo Pati wrote:
>On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
>
>
>
>>I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
>>that much, but it's true that 'sendPage' contains less semantic meaning
>>than 'sendPageAndWait' and therefore might become a little confusing at
>>first. It's a little bit semantically unbalanced and this doesn't
>>reflect in their functional operation.
>>
>>So, let's see, that method is supposed to 'send a page' to the client
>>but is not going to wait for the client to come back and continue. So,
>>the real name would be something like
>>
>> - sendPageAndDontWait
>>
>>but that sucks.
>>
>> - sendPageAndReturn
>>
>>is nice but only if you understand that the flow layer takes control
>>over the sitemap and that 'return' means that you are returning from
>>procedural continuation-based control (the flowscript) to declerative
>>request driven control (the sitemap)
>>
>>So it does have perfect sense for us, but I'm not sure it does for
>>somebody that looks at the flowscript for the first time.
>>
>>But I can't come up with anything better because
>>
>> - sendPageAndExit
>>
>>might be even worse (people might think Cocoon might stop!)
>>
>>Any idea?
>>
>>
>
>As you said above the function does two things:
>
> 1. send a page
> 2. does not wait
>
>So, how about splitting it into two function:
>
> - sendPage
> - getAnswer
>
>
Semantically speaking, this is a _really good_ idea, but... it
unfortunately cannot be implemented that way :(
The reason is that suspending the flow (with getAnswer) involves
creating a continuation object, and that the page that is displayed
(with sendPage) must know the ID of that continuation in order to put it
in page links or form actions that will later on resume that continuation.
So you would need in "sendPage" an information that is given later by
"getAnswer". Chicken and egg problem which requires merging into a
single function the operations of sending a page and waiting (or not)
for the user's input.
See o/a/c.components/flow/javascript/system.js for more details.
Too bad...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 4 Dec 2002, Stefano Mazzocchi wrote:
> I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
> that much, but it's true that 'sendPage' contains less semantic meaning
> than 'sendPageAndWait' and therefore might become a little confusing at
> first. It's a little bit semantically unbalanced and this doesn't
> reflect in their functional operation.
>
> So, let's see, that method is supposed to 'send a page' to the client
> but is not going to wait for the client to come back and continue. So,
> the real name would be something like
>
> - sendPageAndDontWait
>
> but that sucks.
>
> - sendPageAndReturn
>
> is nice but only if you understand that the flow layer takes control
> over the sitemap and that 'return' means that you are returning from
> procedural continuation-based control (the flowscript) to declerative
> request driven control (the sitemap)
>
> So it does have perfect sense for us, but I'm not sure it does for
> somebody that looks at the flowscript for the first time.
>
> But I can't come up with anything better because
>
> - sendPageAndExit
>
> might be even worse (people might think Cocoon might stop!)
>
> Any idea?
As you said above the function does two things:
1. send a page
2. does not wait
So, how about splitting it into two function:
- sendPage
- getAnswer
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Andy Lewis wrote:
> what about I/O terms?
>
> sendPageBlocking
> sendPageNonBlocking
That sounds good. Especially, since the function names are quite short :-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ed <ed...@cyberglide.tv>.
Just lurking,
At 11:44 PM 12/4/2002 -0800, you wrote:
>Andy Lewis wrote:
>>what about I/O terms?
>>sendPageBlocking
>>sendPageNonBlocking
>
>I still like the concept of "waiting" a lot more. In short, your 'server' is waiting for you to come back. It would be like having your personal thread allocated in the server, even if this is not the case.
>
>The best I could think of would be:
>
>sendPageAndHaveYourServerWaitForYouToComeBack
sendPageStateFull
>sendPageAndSetYourServerFreeToServeSomebodyElse
>
sendPageStateLess
ed
>:-D
>
>but of course I'm not proposing these method names :-)
>
>now, somebody with good english skills should srink those concepts down to a reasonable short sentence.
>
>--
>Stefano Mazzocchi <st...@apache.org>
>--------------------------------------------------------------------
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Denis <de...@aic-info.com>.
Just to give an other option:
-SendPageAndWait
-SendPageAndFree
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Thursday, December 05, 2002 8:44 AM
Subject: Re: Changes made to flow system.js
> Andy Lewis wrote:
> > what about I/O terms?
> >
> > sendPageBlocking
> > sendPageNonBlocking
>
> I still like the concept of "waiting" a lot more. In short, your
> 'server' is waiting for you to come back. It would be like having your
> personal thread allocated in the server, even if this is not the case.
>
> The best I could think of would be:
>
> sendPageAndHaveYourServerWaitForYouToComeBack
> sendPageAndSetYourServerFreeToServeSomebodyElse
>
> :-D
>
> but of course I'm not proposing these method names :-)
>
> now, somebody with good english skills should srink those concepts down
> to a reasonable short sentence.
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Miles Elam <mi...@pcextremist.com>.
> Stefano Mazzocchi wrote:
>
>> Andy Lewis wrote:
>>
>>> what about I/O terms?
>>>
>>> sendPageBlocking
>>> sendPageNonBlocking
>>
>> I still like the concept of "waiting" a lot more. In short, your
>> 'server' is waiting for you to come back. It would be like having
>> your personal thread allocated in the server, even if this is not the
>> case.
>
What about:
sendNextPage
sendLastPage
The first implies a continuation (no pun intended) of a sequence of
pages. The second implies the end of a sequence of pages. Why wait?
Coming from page foo1:
doItem1();
sendNextPage(foo2);
doItem2();
sendNextPage(foo3);
doItemN();
sendNextPage(fooN);
finishProcessing();
sendLastPage();
doNecessaryCleanupAndPostprocessing();
You're not waiting. From the conceptual level of the flow script,
you're just doing the next item on the list. The fact that sendNextPage
blocks or takes more time to finish seems to me like a side effect, not
a focus. You're not waiting for the wait to end. You're waiting for
the function to end. It just so happens that the function blocks
internally until an (implementation dependent) event to occur. Wasn't
that the point of the flow system: to make logic fit conceptually into a
natural sequence?
After all, it's
ServerSocket ss = new ServerSocket(80);
Socket s = ss.accept();
and not
ServerSocket ss = new ServerSocket(80);
Socket s = ss.waitForIncomingConnectionUnlessTimeout();
Thoughts?
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Matteo Di Giovinazzo <ma...@infinito.it>.
Stefano Mazzocchi wrote:
> Andy Lewis wrote:
>
>> what about I/O terms?
>>
>> sendPageBlocking
>> sendPageNonBlocking
>
>
> I still like the concept of "waiting" a lot more. In short, your
> 'server' is waiting for you to come back. It would be like having your
> personal thread allocated in the server, even if this is not the case.
>
> The best I could think of would be:
>
> sendPageAndHaveYourServerWaitForYouToComeBack
> sendPageAndSetYourServerFreeToServeSomebodyElse
>
> :-D
>
> but of course I'm not proposing these method names :-)
>
> now, somebody with good english skills should srink those concepts down
> to a reasonable short sentence.
>
What do you think of these method names?
sendPageAndBack()
sendPageAndWait()
CIAO!
--
matteodg = |keip|
<http://unipdleague.sourceforge.net/>
Fantacalcio Università di Padova
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Andy Lewis wrote:
>
>> what about I/O terms?
>>
>> sendPageBlocking
>> sendPageNonBlocking
>
>
> I still like the concept of "waiting" a lot more. In short, your
> 'server' is waiting for you to come back. It would be like having your
> personal thread allocated in the server, even if this is not the case.
>
> The best I could think of would be:
>
> sendPageAndHaveYourServerWaitForYouToComeBack
> sendPageAndSetYourServerFreeToServeSomebodyElse
>
> :-D
>
> but of course I'm not proposing these method names :-)
>
> now, somebody with good english skills should srink those concepts down
> to a reasonable short sentence.
trying...
> sendPageAndHaveYourServerWaitForYouToComeBack
sendPageAndGetReply
sendPageAndWait
sendPageForInput
> sendPageAndSetYourServerFreeToServeSomebodyElse
sendPageAndContinue
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Andy Lewis wrote:
> what about I/O terms?
>
> sendPageBlocking
> sendPageNonBlocking
I still like the concept of "waiting" a lot more. In short, your
'server' is waiting for you to come back. It would be like having your
personal thread allocated in the server, even if this is not the case.
The best I could think of would be:
sendPageAndHaveYourServerWaitForYouToComeBack
sendPageAndSetYourServerFreeToServeSomebodyElse
:-D
but of course I'm not proposing these method names :-)
now, somebody with good english skills should srink those concepts down
to a reasonable short sentence.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Andy Lewis <aj...@ascii27.net>.
what about I/O terms?
sendPageBlocking
sendPageNonBlocking
or something akin to these?
> Sylvain Wallez wrote:
>> Michael Melhem wrote:
>>
>>> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
>>>
>>>
>>>> Marcus Crafter wrote:
>>>>
>>>>> Hi Troops!
>>>>>
>>>>> Hope all is well.
>>>>>
>>>>> I've just checked in BZ#14903 which changes the names of the
>>>>> flow sendPage* functions as previously discussed in the 'flow wishlist' thread.
>>>>>
>>>>> Unfortunately the change is *not* backwards compatible so please
>>>>> be careful and update any flow code you might have locally after
>>>>> updating.
>>>>>
>>>>> The changes are:
>>>>>
>>>>> sendPage() becomes sendPageAndWait()
>>>>> sendPageAndContinue() becomes sendPage()
>>>>>
>>>>> The last one is the tricky one because the method names are essentially swapped.
>>>>>
>>>>>
>>>>
>>>> Just some thoughts (sorry if this already has been discussed, I may have missed it) : why
>>>> not keeping the "sendPageAndContinue" ?
>>>>
>>>
>>>
>>> sendPageAndContinue is precisely the problem, many people were confusing "Continue" with
>>> continuations!
>>>
>>>
>>
>> Ah, ok, I understand... but I'm still uncomfortable with having a precise "sendPageAndWait"
>> and an imprecise "sendPage", as inconsistent naming always leads to confusion.
>>
>> So, last try : what about "sendPageAndReturn" ?
>
> I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn' that much, but it's true
> that 'sendPage' contains less semantic meaning than 'sendPageAndWait' and therefore might
> become a little confusing at first. It's a little bit semantically unbalanced and this doesn't
> reflect in their functional operation.
>
> So, let's see, that method is supposed to 'send a page' to the client but is not going to wait
> for the client to come back and continue. So, the real name would be something like
>
> - sendPageAndDontWait
>
> but that sucks.
>
> - sendPageAndReturn
>
> is nice but only if you understand that the flow layer takes control over the sitemap and that
> 'return' means that you are returning from procedural continuation-based control (the
> flowscript) to declerative request driven control (the sitemap)
>
> So it does have perfect sense for us, but I'm not sure it does for somebody that looks at the
> flowscript for the first time.
>
> But I can't come up with anything better because
>
> - sendPageAndExit
>
> might be even worse (people might think Cocoon might stop!)
>
> Any idea?
>
> --
> Stefano Mazzocchi <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Michael Melhem wrote:
>
>> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
>>
>>
>>> Marcus Crafter wrote:
>>>
>>>> Hi Troops!
>>>>
>>>> Hope all is well.
>>>>
>>>> I've just checked in BZ#14903 which changes the names of the
>>>> flow sendPage* functions as previously discussed in the 'flow
>>>> wishlist' thread.
>>>>
>>>> Unfortunately the change is *not* backwards compatible so please
>>>> be careful and update any flow code you might have locally after
>>>> updating.
>>>>
>>>> The changes are:
>>>>
>>>> sendPage() becomes sendPageAndWait()
>>>> sendPageAndContinue() becomes sendPage()
>>>>
>>>> The last one is the tricky one because the method names are
>>>> essentially swapped.
>>>>
>>>>
>>>
>>> Just some thoughts (sorry if this already has been discussed, I may
>>> have missed it) : why not keeping the "sendPageAndContinue" ?
>>>
>>
>>
>> sendPageAndContinue is precisely the problem, many people were
>> confusing "Continue" with continuations!
>>
>>
>
> Ah, ok, I understand... but I'm still uncomfortable with having a
> precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent
> naming always leads to confusion.
>
> So, last try : what about "sendPageAndReturn" ?
I think Sylvain has a point. I'm not sure I like 'sendPageAndReturn'
that much, but it's true that 'sendPage' contains less semantic meaning
than 'sendPageAndWait' and therefore might become a little confusing at
first. It's a little bit semantically unbalanced and this doesn't
reflect in their functional operation.
So, let's see, that method is supposed to 'send a page' to the client
but is not going to wait for the client to come back and continue. So,
the real name would be something like
- sendPageAndDontWait
but that sucks.
- sendPageAndReturn
is nice but only if you understand that the flow layer takes control
over the sitemap and that 'return' means that you are returning from
procedural continuation-based control (the flowscript) to declerative
request driven control (the sitemap)
So it does have perfect sense for us, but I'm not sure it does for
somebody that looks at the flowscript for the first time.
But I can't come up with anything better because
- sendPageAndExit
might be even worse (people might think Cocoon might stop!)
Any idea?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Joerg Heinicke <jo...@gmx.de>.
> BTW, I know "Tisch" which means "table", but what does "Stamm" mean ?
http://dict.tu-chemnitz.de/dings.cgi?lang=de&noframes=0&query=stammtisch&service=&optword=1&optcase=1&opterrors=0&optpro=0&self=1
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>On Wed, Dec 04, 2002 at 02:56:50PM +0100, Sylvain Wallez wrote:
>
>
<snip/>
>>>>Just some thoughts (sorry if this already has been discussed, I may have
>>>>missed it) : why not keeping the "sendPageAndContinue" ?
>>>>
>>>sendPageAndContinue is precisely the problem, many people were
>>>confusing "Continue" with continuations!
>>>
>>Ah, ok, I understand... but I'm still uncomfortable with having a
>>precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent
>>naming always leads to confusion.
>>
>>
>Yes I know what you mean. hmmm...
>
>>So, last try : what about "sendPageAndReturn" ?
>>
>>
>This name was already suggested, but Ovidiu had some objection to "Return". ???
>
>
OK. I give up... until some user complains ;-)
>BTW, are you coming to the Stammtisch too? ;)
>
Unfortunately no. Two Cocooners meetings in a month is too much :-/
Next one, maybe (the Frankfurter Cocoon Club seems to organize this often).
BTW, I know "Tisch" which means "table", but what does "Stamm" mean ?
Cheers,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Ovidiu Predescu <ov...@apache.org>.
On Wednesday, Dec 4, 2002, at 06:30 US/Pacific, Michael Melhem wrote:
> On Wed, Dec 04, 2002 at 02:56:50PM +0100, Sylvain Wallez wrote:
>> Michael Melhem wrote:
>>
>>> On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
>>>
>>>
>>>> Marcus Crafter wrote:
>>>>
>>>> Just some thoughts (sorry if this already has been discussed, I may
>>>> have
>>>> missed it) : why not keeping the "sendPageAndContinue" ?
>>>>
>>>>
>>>
>>> sendPageAndContinue is precisely the problem, many people were
>>> confusing "Continue" with continuations!
>>>
>>>
>>
>> Ah, ok, I understand... but I'm still uncomfortable with having a
>> precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent
>> naming always leads to confusion.
>
> Yes I know what you mean. hmmm...
I agree, I was thinking about exactly this last night.
>> So, last try : what about "sendPageAndReturn" ?
>
> This name was already suggested, but Ovidiu had some objection to
> "Return". ???
People usually associate "return" with returning from the current
function. I'm still looking for a better name to mean the function
sends the response page, but continues the processing of the script
without creating a continuation and stopping. I personally still prefer
the sendPageAndContinue, now that we have sendPageAndWait it should be
clear the meaning of "Continue".
> BTW, are you coming to the Stammtisch too? ;)
I don't know about Sylvain, but I'm still thinking about it ;)
Ovidiu
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Dec 04, 2002 at 02:56:50PM +0100, Sylvain Wallez wrote:
> Michael Melhem wrote:
>
> >On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
> >
> >
> >>Marcus Crafter wrote:
> >>
> >>>Hi Troops!
> >>>
> >>> Hope all is well.
> >>>
> >>> I've just checked in BZ#14903 which changes the names of the flow
> >>> sendPage* functions as previously discussed in the 'flow wishlist'
> >>> thread.
> >>>
> >>> Unfortunately the change is *not* backwards compatible so please be
> >>> careful and update any flow code you might have locally after
> >>> updating.
> >>>
> >>> The changes are:
> >>>
> >>> sendPage() becomes sendPageAndWait()
> >>> sendPageAndContinue() becomes sendPage()
> >>>
> >>> The last one is the tricky one because the method names are
> >>> essentially swapped.
> >>>
> >>>
> >>>
> >>Just some thoughts (sorry if this already has been discussed, I may have
> >>missed it) : why not keeping the "sendPageAndContinue" ?
> >>
> >>
> >
> >sendPageAndContinue is precisely the problem, many people were
> >confusing "Continue" with continuations!
> >
> >
>
> Ah, ok, I understand... but I'm still uncomfortable with having a
> precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent
> naming always leads to confusion.
Yes I know what you mean. hmmm...
> So, last try : what about "sendPageAndReturn" ?
This name was already suggested, but Ovidiu had some objection to "Return". ???
BTW, are you coming to the Stammtisch too? ;)
Regards,
Michael Melhem
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Michael Melhem wrote:
>On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
>
>
>>Marcus Crafter wrote:
>>
>>>Hi Troops!
>>>
>>> Hope all is well.
>>>
>>> I've just checked in BZ#14903 which changes the names of the flow
>>> sendPage* functions as previously discussed in the 'flow wishlist'
>>> thread.
>>>
>>> Unfortunately the change is *not* backwards compatible so please be
>>> careful and update any flow code you might have locally after
>>> updating.
>>>
>>> The changes are:
>>>
>>> sendPage() becomes sendPageAndWait()
>>> sendPageAndContinue() becomes sendPage()
>>>
>>> The last one is the tricky one because the method names are
>>> essentially swapped.
>>>
>>>
>>>
>>Just some thoughts (sorry if this already has been discussed, I may have
>>missed it) : why not keeping the "sendPageAndContinue" ?
>>
>>
>
>sendPageAndContinue is precisely the problem, many people were
>confusing "Continue" with continuations!
>
>
Ah, ok, I understand... but I'm still uncomfortable with having a
precise "sendPageAndWait" and an imprecise "sendPage", as inconsistent
naming always leads to confusion.
So, last try : what about "sendPageAndReturn" ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Dec 04, 2002 at 02:19:33PM +0100, Sylvain Wallez wrote:
> Marcus Crafter wrote:
>
> >Hi Troops!
> >
> > Hope all is well.
> >
> > I've just checked in BZ#14903 which changes the names of the flow
> > sendPage* functions as previously discussed in the 'flow wishlist'
> > thread.
> >
> > Unfortunately the change is *not* backwards compatible so please be
> > careful and update any flow code you might have locally after
> > updating.
> >
> > The changes are:
> >
> > sendPage() becomes sendPageAndWait()
> > sendPageAndContinue() becomes sendPage()
> >
> > The last one is the tricky one because the method names are
> > essentially swapped.
> >
>
> Just some thoughts (sorry if this already has been discussed, I may have
> missed it) : why not keeping the "sendPageAndContinue" ?
sendPageAndContinue is precisely the problem, many people were
confusing "Continue" with continuations!
Cheers,
Michael Melhem
>
> This would remove any ambiguity that may be attached to the somewhat
> imprecise "sendPage".
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marcus Crafter wrote:
>Hi Troops!
>
> Hope all is well.
>
> I've just checked in BZ#14903 which changes the names of the flow sendPage* functions as previously discussed in the 'flow wishlist' thread.
>
> Unfortunately the change is *not* backwards compatible so please be careful and update any flow code you might have locally after updating.
>
> The changes are:
>
> sendPage() becomes sendPageAndWait()
> sendPageAndContinue() becomes sendPage()
>
> The last one is the tricky one because the method names are essentially swapped.
>
Just some thoughts (sorry if this already has been discussed, I may have
missed it) : why not keeping the "sendPageAndContinue" ?
This would remove any ambiguity that may be attached to the somewhat
imprecise "sendPage".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Wed, Dec 04, 2002 at 01:48:06PM +0100, Michael Melhem wrote:
>
> Actually, documenation in samples/flow/docs/continuations.xml still
> refers to the old sendPage* methods... ooops need fix this too.
Fixed. Thanks for the pointer :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Changes made to flow system.js
Posted by Michael Melhem <mi...@fztig938.bank.dresdner.net>.
On Wed, Dec 04, 2002 at 12:26:42PM +0100, Marcus Crafter wrote:
> Hi Troops!
>
> Hope all is well.
>
> I've just checked in BZ#14903 which changes the names of the flow
> sendPage* functions as previously discussed in the 'flow wishlist'
> thread.
>
> Unfortunately the change is *not* backwards compatible so please be
> careful and update any flow code you might have locally after updating.
>
> The changes are:
>
> sendPage() becomes sendPageAndWait()
> sendPageAndContinue() becomes sendPage()
Actually, documenation in samples/flow/docs/continuations.xml still
refers to the old sendPage* methods... ooops need fix this too.
Regards,
Michael Melhem
>
> The last one is the tricky one because the method names are
> essentially swapped.
>
> The changes themselves were discussed in the following threads:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103796994100696&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103798846821855&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103834225818942&w=2
>
> If there's any problems please let me know.
>
> Cheers,
>
> Marcus
>
>
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: ManageSoft GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&'
> &&&&.
> &&&&&&&:
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org