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 al
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
de
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 <=> sen
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 pe
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
>> 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' an
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 al
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 ac
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 discuss
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
Chri
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
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
sendPageAnd
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.
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 continuatio
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 imp
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 fa
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 conce
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 earli
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 earli
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" ? T
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
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
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,
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) S
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
>> 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
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...
onl
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 r
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
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
af
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
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
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.
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 thi
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 thi
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 'sendPageAndWa
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()
> >
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 l
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
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 semanti
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 t
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:
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?
sendPageBlock
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
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
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]>
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
---
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]
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:
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 wel
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
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 b
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 P
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
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
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
--
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.
Un
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'
> >
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 c
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.
>
> U
60 matches
Mail list logo
