Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Ugo Cei]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Ovidiu Predescu]

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:

H, 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]

[Ovidiu Predescu]

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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]

[Miles Elam]

Hunsberger, Peter wrote:


So, my proposal would be

 sendScreen(uri, data);

...

sendPage(uri, data);
   

Ugg, although I can see a semantic difference between a form and a page I'll
be darned if I can see a semantic difference between a screen and a page
(given that we're not dealing with page oriented media in most cases
anyway)...


Agreed.  Add in the fact that automated agents don't have a screen per 
se but still fill out forms.  Web developers already understand the 
concept of a form.

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

Seems much better to me!


Yes!  To me as well.

- Miles



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]

[Hunsberger, Peter]

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

Ugg, although I can see a semantic difference between a form and a page I'll
be darned if I can see a semantic difference between a screen and a page
(given that we're not dealing with page oriented media in most cases
anyway)...

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

Seems much better to me!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Ed]

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   <[EMAIL PROTECTED]>
>
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Ugo Cei]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Konstantin Piroumian]

From: "Christian Haul" <[EMAIL PROTECTED]>
> On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:
> 
> 
> 
> > 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
> [EMAIL PROTECTED]
> fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Christian Haul]

On 09.Dec.2002 -- 10:40 AM, Ovidiu Predescu wrote:



> 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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Giacomo Pati]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Wrap-up for flow functions [WAS Re: Changes made to flow system.js]

[Ovidiu Predescu]

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:

H, 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Christian Haul]

On 08.Dec.2002 -- 03:48 PM, Stefano Mazzocchi wrote:
> H, 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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Christopher Oliver]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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. H, h, h (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.

H, 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 o

Re: Changes made to flow system.js

[Miles Elam]

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 flo

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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.

Re: Changes made to flow system.js

[Ovidiu Predescu]

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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Ovidiu Predescu]

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 t

Re: Changes made to flow system.js

[Ovidiu Predescu]

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:


H..  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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Miles Elam]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Giacomo Pati]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Changes made to flow system.js

[Hunsberger, Peter]

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

Well, as I've recently learned, it seems you're not really sending a page,
rather you are asking for the processing of a URI.  As such I'd suggest
something more like:

resolveURIandWait()
resolveURIandContinue()




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Christian Haul]

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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,

Re: Changes made to flow system.js

[Marc Portier]

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 Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Christian Haul]

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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Michael Melhem]

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)
> >
> >H..  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 <[EMAIL PROTECTED]>
> http://webweavertech.com/ovidiu/weblog/
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Ovidiu Predescu]

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)

H..  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 <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Miles Elam]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Matteo Di Giovinazzo]

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|

   
 Fantacalcio Università di Padova



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Giacomo Pati]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Michael Melhem]

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

H..  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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Sylvain Wallez]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Sylvain Wallez]

Ovidiu Predescu wrote:



On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:




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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Giacomo Pati]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Nicola Ken Barozzi]

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   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Denis]

Just to give an other option:

-SendPageAndWait
-SendPageAndFree

- Original Message - 
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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   <[EMAIL PROTECTED]>
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Ovidiu Predescu]

On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:




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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

Jason Foster wrote:



How about thinking in terms of synchronous and asynchronous I/O?

sendPageAndBlock() or sendPageSync()
sendPageAsync()


Nah, it might even get more confusing.

--
Stefano Mazzocchi   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Christian Haul]

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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Jason Foster]

How about thinking in terms of synchronous and asynchronous I/O?

sendPageAndBlock() or sendPageSync()
sendPageAsync()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Changes made to flow system.js

[Artur Bialecki]

How about:

 sendAndSuspend
 sendAndResume

Artur...
  

> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] 
> Sent: December 4, 2002 4:07 PM
> To: [EMAIL PROTECTED]
> 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   <[EMAIL PROTECTED]>
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Andy Lewis]

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   <[EMAIL PROTECTED]>
> 
>
>
>
> - To 
>unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


-- 
"The heights of genius are only measurable by the depths of stupidity."



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Stefano Mazzocchi]

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   <[EMAIL PROTECTED]>




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Ovidiu Predescu]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Joerg Heinicke]

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
[EMAIL PROTECTED]
www.virbus.de


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Sylvain Wallez]

Michael Melhem wrote:


On Wed, Dec 04, 2002 at 02:56:50PM +0100, Sylvain Wallez 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...


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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Michael Melhem]

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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Marcus Crafter]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Sylvain Wallez]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Michael Melhem]

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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Sylvain Wallez]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Changes made to flow system.js

[Michael Melhem]

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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]