Stefano Mazzocchi wrote:
good argument, but do you only solve this with naming?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
sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoes("bar");
or
sendLastPage();
sendNextPage(); //sorry, wasn't the last after all?
would offer you the same dillema
as would even:
sendPageWhateverSuffixThatDoesntWait("foo");
sendPageWhateverSuffixThatDoesntWait("bar");
a discussion we also had earlier in the thread...
and which you pointed out so clearly with the remark that *this all* keeps on being a servlet generating a simple response (not a screen we can add a line to)
The question Michael posed keeps on being not solved:
On 06.Dec.2002 -- 11:09 AM, Michael Melhem wrote:On Thu, Dec 05, 2002 at 10:45:38PM -0800, Ovidiu Predescu wrote:> "Finish" what? The problem with that is that you could still do things > after the page was sent back to the client. Advanced users might want > to use this fact to do all sorts of nasty things.
Interesting, didnt think of that. So does this mean you can send multiple pages back to the client without client intereaction.. ?
Anyone? For me, as for Miles Elam:
I don't mean to butt in when I haven't contributed to flow, but as I will be a user of this API, obscure function semantics aren't going to make my life easier when I teach others how to use it.
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
