On Thu, Dec 05, 2002 at 09:29:23AM +0100, Sylvain Wallez wrote:
> Ovidiu Predescu wrote:
>
> >
> >On Wednesday, Dec 4, 2002, at 13:11 US/Pacific, Jason Foster wrote:
> >
> >><snip/>
> >>
> >>How about thinking in terms of synchronous and asynchronous I/O?
> >>
> >>sendPageAndBlock() or sendPageSync()
> >>sendPageAsync()
> >
> >
> >On Wednesday, Dec 4, 2002, at 14:33 US/Pacific, Andy Lewis wrote:
> >
> >>
> >>what about I/O terms?
> >>
> >>sendPageBlocking
> >>sendPageNonBlocking
> >>
> >>or something akin to these?
> >
> >
> >I think the danger is to have the semantics of these functions
> >associated with the way the response page is actually sent over the wire.
> >
> >To reiterate my option, I think sendPageAndWait and
> >sendPageAndContinue are still the best options. They also provide the
> >maximum compatibility with the old naming, only sendPage dissapears,
> >everything else is the same.
>
>
> Agree. I think the confusion of "sendPageAndContinue" with continuations
> came from the fact that the "sendPage" counterpart wasn't semantically
> precise enough.
>
> Most people seem to agree that "sendPageAndWait" is a good name. My
> english skills tell me that "continue" is a good word as a complementary
> to "wait". And since my skills are somewhat limited, it's likely that it
> most people will have the same understanding as me :)
>
> So, IMO, "sendPageAndWait" and "sendPageAndContinue", are good names,
> being equally-precise and semantically complementary.
Yes I agree (like most) that sendPageAndWait is the best name, because it
implies that flow "waits" here for a response. (even though techinically
this is not true)
+1
The "wait" here is in the context of the of the flow method...its the flow
method that waits..but continue in sendPageAndContinue makes sense only in the
context of the sitemap processing, its the sitemap that continues its
processing. This requires a context change in understanding which I find
confusing (and breaks the wait/continue symmetry). Without this context shift,
one might think its that the flow method that continues - as apposed to waiting.
Also, a flow method need not have a "sendPageAndWait". Example:
flow()
{
.....
if (something)
sendPageAndContiue(page1)
else
sendPageAndContiue(page2)
}
so in this case, continue could be interepted as "create continuation" as there
is no "wait" to contrast it with.
So as for sendPageAndContinue, I vote
-0.25 (hmm .. im not totally against it)
Hmmmm.. we could end up disussing semantics forever,
but how about "sendPageAndFinish" ? Thats the only alternative i can think of
at the moment. So one would have:
flow()
{
sendPageAndWait
..
sendPageAndWait
..
sendPageAndFinish
}
Best regards,
Michael Melhem
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
