Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On 7 Nov 2003, at 17:22, Guido Casper wrote: Stefano Mazzocchi wrote: On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote: Stefano Mazzocchi wrote: On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote: I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. -1 Your -1 means: "replace later with never", right? Just to remove any possible point of confusion :) yes. I am against the silly ... do something if true .. do something if false syntax. doesn't matter what the logic that drives the "xxx" tag is or what "xxx" is remapped to. Wow, that would rule out matchers as well. But it might make some sense since matchers are not all that different to actions ;-) Careful. I'm against the use of as well. The proper way should be ... having the logic processing not following the element nesting, is, IMO, very confusing and very bad practice. In the original sitemap design, it was *NOT* possible to have pipeline components inside , only matchers. This is something that was introduced while I wasn't watching, just like actions. Yes, actions are not the only the only things I dislike about the sitemap: the tree processor introduced new ways of dealing with things (like having resources without generators or serializers, or pipeline components in pipelines without matchers)... but all these things ended up being more harm than good from a usage perspective. So, what's the point of introducing something and then come out with "best practices" that prevent you from using them? -- Stefano.
change subjects please (was Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status])
Is this even still a vote? It seems that it has devolved into a conversation. Perhaps a change in title will get more people in on the conversation--or perhaps turning it into an RT would help. Being drakonian on messages with [VOTE] in the title will make it clear if we are still voting or not. I don't even know what the outcome of the vote was. Guido Casper wrote: Stefano Mazzocchi wrote: On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote: Stefano Mazzocchi wrote: On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote: I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. -1 Your -1 means: "replace later with never", right? Just to remove any possible point of confusion :) yes. I am against the silly ... do something if true .. do something if false syntax. doesn't matter what the logic that drives the "xxx" tag is or what "xxx" is remapped to. Wow, that would rule out matchers as well. But it might make some sense since matchers are not all that different to actions ;-) Guido
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Stefano Mazzocchi wrote: > On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote: > >> Stefano Mazzocchi wrote: >> >>> >>> On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko >>> wrote: >>> I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. >>> >>> >>> -1 >> >> >> Your -1 means: "replace later with never", right? Just to remove any >> possible point of confusion :) > > yes. I am against the silly > > >... do something if true > > .. do something if false > > syntax. doesn't matter what the logic that drives the "xxx" tag is or > what "xxx" is remapped to. Wow, that would rule out matchers as well. But it might make some sense since matchers are not all that different to actions ;-) Guido
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On 7 Nov 2003, at 13:52, Vadim Gritsenko wrote: Stefano Mazzocchi wrote: On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote: I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. -1 Your -1 means: "replace later with never", right? Just to remove any possible point of confusion :) yes. I am against the silly ... do something if true .. do something if false syntax. doesn't matter what the logic that drives the "xxx" tag is or what "xxx" is remapped to. -- Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Stefano Mazzocchi wrote: On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote: I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. -1 Your -1 means: "replace later with never", right? Just to remove any possible point of confusion :) I want to arrive to a point in the future where the ugly element and silly usage can be thrown away without nobody whining. We will get there. Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
- cocoon.sendStatus(status) - cocoon.sendStatus(status, message) - cocoon.response.setStatus(status) - cocoon.response.setStatus(status,message) +4 from me +1 -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Unico Hommes wrote: > I am +1 on the idea but would favor naming the method sendStatus > instead, and also have a way to set the status on the environment from > the flow without sending an empty response: > > - cocoon.sendStatus(status) > - cocoon.sendStatus(status, message) > - cocoon.response.setStatus(status) > - cocoon.response.setStatus(status,message) +1 Guido
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Thursday, Nov 6, 2003, at 14:39 Europe/Rome, Vadim Gritsenko wrote: I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. -1 I want to arrive to a point in the future where the ugly element and silly usage can be thrown away without nobody whining. Action -> flow migration paths exists today. We don't need to reiterate past mistakes over and over. -- Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Stefano Mazzocchi wrote: On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote: ... Before we vote: how to resolve "flow actions" issue then? There should be migration path for users who already have wrote an actions wtih flow. (remember? you've said that actions should be replaced with flowscript ;-) You teaser ;-) IMVHO, an action is an overlap of three concerns: 1) processing logic external to the sitemap used to drive its flow 2) processing logic external to the pipelines used to drive its creation 3) processing logic used to update the external environment A potential migration strategy is: 1) should be done in the flow, either rewriting in javascript or refactoring the logic, moving it into an isolated component (either avalon or simple java class to instantiate from the flow) 3) this should be refactored into a class or component which leaves us with 2). I've seen far too many actions that set parameters that are later used by selectors. This is WRONG!!! You should be writing a selector!!! But at the very end, I think the issues at stake are orthogonal: Unico and I want a simple way to generate reponses with empty-payloads because this is going to be common for more complex uses of HTTP. You propose to clone the ugly action-like sitemap semantics with flowscript logic. No, I don't. I'm just teasing ;-) I'd like to see following: 1) If flow calls sendPage*(), sitemap execution terminates. 2) If flow calls sendStatus(), sitemap execution terminates. 3) If flow does none of the above, sitemap execution continues. I think we have already consensus on (1) and (2). (3) is the current behavior which can stay. I agree with comments in this other thread that let's not introduce nested components in . Instead, if needed, let's introduce . Sometime later. Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Unico Hommes wrote: I am +1 on the idea but would favor naming the method sendStatus instead, and also have a way to set the status on the environment from the flow without sending an empty response: - cocoon.sendStatus(status) - cocoon.sendStatus(status, message) - cocoon.response.setStatus(status) - cocoon.response.setStatus(status,message) +1 Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Thursday, Nov 6, 2003, at 09:37 Europe/Rome, Unico Hommes wrote: I am +1 on the idea but would favor naming the method sendStatus instead, and also have a way to set the status on the environment from the flow without sending an empty response: - cocoon.sendStatus(status) - cocoon.sendStatus(status, message) - cocoon.response.setStatus(status) - cocoon.response.setStatus(status,message) +4 from me +1, fair enough: an empty HTTP response is, in fact and in REST termonology, a description of the server status. -- Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Unico Hommes wrote: -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: woensdag 5 november 2003 15:12 To: [EMAIL PROTECTED] Unico Hommes wrote: Null would mean a pipeline is not required to be executed. -1 : we must have an explicit call to an environment-related method that allows to detect if the application tries to send content back afterwards. And this should not be available only in the flow as we may want to do the same in an action. I see. .. And if sendStatus() and sendError() don't fit, let's do our own sendEmptyResponse(int status, String message). sendStatus(int status, String message) sets the hasRedirected flag to true. setStatus(int status) doesn't. Perhaps this is correct way of doing it. I like it. +1. Vadim
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
> -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: woensdag 5 november 2003 15:25 > To: [EMAIL PROTECTED] > Subject: Re: [Vote] empty HTTP responses [was Re: Cannot > easily set http status] > > > > On Wednesday, Nov 5, 2003, at 14:20 Europe/Rome, Unico Hommes wrote: > > >> From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] > > >> Sorry to jump in late, I'm probably lagging behind a few > posts, but > >> was the possibility of having *pipelines* send empty payload > >> considered instead? This way flow will always have to > sendPage(), but > >> the result would be empty content anyway. With the added bonus of > >> having the pipeline flexibility to, say, set headers. > >> > > > > But the function of a pipeline is specifically towards the > production > > of > > an xml response body. To have to set up all the components, > execute the > > pipeline and then fooling the pipeline to send its data to a null > > output > > or refrain from pipeline execution altogether? In some > scenarios that > > may be necessary, for instance in the case of the http HEAD > function. > > The point is, you shouldn't have to, because there are a lot of > > situations where its just unneccesary overhead. (for example all the > > dummy responses in the davmap sitemap) > > I'm with Unico here: the use of HTTP in a DeltaV scenario is > *massive* > and involves tons of requests/responses for even a simple operation > like moving a file. Many of these responses have no payload as the > result is contained in the response headers. > > Note, this *does not* imply that you shouldn't be able to use a > pipeline to do further processing (even if it results in no payload), > but I think it should *not* be forced upon us to have a "dummy > pipeline" just to satisfy these contraints. > > Different story for Reinhard's concern, I think it's a valid point: > most situations on the web handle requests that return a payload... > having a way to signal that "hey, you are missing your payload" is a > good debugging advice and we wouldn't want to loose this for those > "rare" (in comparison) payload-less responses. > > So, what about > > cocoon.sendEmptyResponse(status-code) > > ? > I am +1 on the idea but would favor naming the method sendStatus instead, and also have a way to set the status on the environment from the flow without sending an empty response: - cocoon.sendStatus(status) - cocoon.sendStatus(status, message) - cocoon.response.setStatus(status) - cocoon.response.setStatus(status,message) +4 from me Cheers, Unico > -- > Stefano. > >
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Wednesday, Nov 5, 2003, at 13:41 Europe/Rome, Vadim Gritsenko wrote: Stefano Mazzocchi wrote: On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Vote? Before we vote: how to resolve "flow actions" issue then? There should be migration path for users who already have wrote an actions wtih flow. (remember? you've said that actions should be replaced with flowscript ;-) You teaser ;-) IMVHO, an action is an overlap of three concerns: 1) processing logic external to the sitemap used to drive its flow 2) processing logic external to the pipelines used to drive its creation 3) processing logic used to update the external environment A potential migration strategy is: 1) should be done in the flow, either rewriting in javascript or refactoring the logic, moving it into an isolated component (either avalon or simple java class to instantiate from the flow) 3) this should be refactored into a class or component which leaves us with 2). I've seen far too many actions that set parameters that are later used by selectors. This is WRONG!!! You should be writing a selector!!! But at the very end, I think the issues at stake are orthogonal: Unico and I want a simple way to generate reponses with empty-payloads because this is going to be common for more complex uses of HTTP. You propose to clone the ugly action-like sitemap semantics with flowscript logic. The votes can happen independently. ]-- Stefano.
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Different story for Reinhard's concern, I think it's a valid point: > most situations on the web handle requests that return a payload... > having a way to signal that "hey, you are missing your payload" is a > good debugging advice and we wouldn't want to loose this for those > "rare" (in comparison) payload-less responses. > > So, what about > > cocoon.sendEmptyResponse(status-code) > +1 Reinhard
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Stefano Mazzocchi wrote: On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Vote? Before we vote: how to resolve "flow actions" issue then? There should be migration path for users who already have wrote an actions wtih flow. (remember? you've said that actions should be replaced with flowscript ;-) Vadim
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Wednesday, Nov 5, 2003, at 14:28 Europe/Rome, Gianugo Rabellino wrote: Unico Hommes wrote: -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: woensdag 5 november 2003 14:02 To: [EMAIL PROTECTED] Stefano Mazzocchi wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in > errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Sorry to jump in late, I'm probably lagging behind a few posts, but was the possibility of having *pipelines* send empty payload considered instead? This way flow will always have to sendPage(), but the result would be empty content anyway. With the added bonus of having the pipeline flexibility to, say, set headers. But the function of a pipeline is specifically towards the production of an xml response body. To have to set up all the components, execute the pipeline and then fooling the pipeline to send its data to a null output or refrain from pipeline execution altogether? In some scenarios that may be necessary, for instance in the case of the http HEAD function. The point is, you shouldn't have to, because there are a lot of situations where its just unneccesary overhead. (for example all the dummy responses in the davmap sitemap) I sure can see some use of this. In a few cases (think PUT) you might have XML input flowing through the pipeline (say you might want to transform it) yet you have to send an empty response: in this scenario using a pipeline looks like the best option to me. I agree that there are situations where it makes sense to go thru a pipeline even for potentially emtpy responses, but I also see tons of reasons to avoid going thru a pipeline again. Also, I feel that the sitemap is core and flow, while being core, is somehow "piggybacked" on the sitemap. I tend to think, then, that deciding whether to send output or not should belong more to the sitemap than to the flow. h, The sitemap is core in the fact that the flowscript function is still matched there... but deciding the output in case of an empty response is a concern of the "programmatical side of things", of the logic that "controls the flow" of hte application, not of the logic that drives the generation of the payload. phisolophical issue, I agree, and hardly objective, but the more complex the webapp becomes (and webdavapps tend to be *very* complex from a flow perspective even for very simple cases) the more stuff should be done in the flow (and in java components directly called by the flow!) and less in the pipeline. pipeline should deal with content, flow should deal with headers. of course, your mileage may vary, but that's a potential design pattern that you might want to use to "measure" how you are writing your webdavapp ... but this is such a undiscovered land that I might just be dead wrong. but my gut feeling tells me that webdavapps will have a lot more flow than pipelines. -- Stefano.
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
>
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: woensdag 5 november 2003 15:12
> To: [EMAIL PROTECTED]
>
> Unico Hommes wrote:
>
> >
> >
> >
> >
> >>-Original Message-
> >>From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> >>Sent: woensdag 5 november 2003 13:55
> >>To: [EMAIL PROTECTED]
> >>
> >>Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard
> Poetz a écrit
> >>:
> >>
> >>
> >>>...I'm +1 with the idea to send pages without payload but
> -0 with flowscripts which terminate without calling
> sendPage*. I would prefer an explicit way
> >>>
> >>>
> >>Same here: flowscripts should not hide the fact that a
> response is indeed sent.
> >>
> >>
> >>
> >
> >I suggested on the other thread that we could use "return
> null" as a signal for that.
> >
> >function put() {
> > doput();
> > setStatus(201);
> > return null;
> >}
> >
> >Null would mean a pipeline is not required to be executed.
> >
> >
> >
>
> -1 : we must have an explicit call to an environment-related
> method that allows to detect if the application tries to send
> content back afterwards. And this should not be available
> only in the flow as we may want to do the same in an action.
>
I see.
> That's why I proposed a redirect to a special "null"
> pseudo-protocol, as once a redirect has been set the sitemap
> engine stops further processing (unless it's a "cocoon:"
> redirect). But this may not be the cleanest way and we may
> better use a method on the response object. And if
> sendStatus() and sendError() don't fit, let's do our own
> sendEmptyResponse(int status, String message).
>
sendStatus(int status, String message) sets the hasRedirected flag to true.
setStatus(int status) doesn't.
Perhaps this is correct way of doing it.
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting,
> Projects } Orixo, the opensource XML business alliance -
> http://www.orixo.com
>
>
>
>
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Wednesday, Nov 5, 2003, at 14:20 Europe/Rome, Unico Hommes wrote: From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sorry to jump in late, I'm probably lagging behind a few posts, but was the possibility of having *pipelines* send empty payload considered instead? This way flow will always have to sendPage(), but the result would be empty content anyway. With the added bonus of having the pipeline flexibility to, say, set headers. But the function of a pipeline is specifically towards the production of an xml response body. To have to set up all the components, execute the pipeline and then fooling the pipeline to send its data to a null output or refrain from pipeline execution altogether? In some scenarios that may be necessary, for instance in the case of the http HEAD function. The point is, you shouldn't have to, because there are a lot of situations where its just unneccesary overhead. (for example all the dummy responses in the davmap sitemap) I'm with Unico here: the use of HTTP in a DeltaV scenario is *massive* and involves tons of requests/responses for even a simple operation like moving a file. Many of these responses have no payload as the result is contained in the response headers. Note, this *does not* imply that you shouldn't be able to use a pipeline to do further processing (even if it results in no payload), but I think it should *not* be forced upon us to have a "dummy pipeline" just to satisfy these contraints. Different story for Reinhard's concern, I think it's a valid point: most situations on the web handle requests that return a payload... having a way to signal that "hey, you are missing your payload" is a good debugging advice and we wouldn't want to loose this for those "rare" (in comparison) payload-less responses. So, what about cocoon.sendEmptyResponse(status-code) ? -- Stefano.
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Unico Hommes wrote:
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: woensdag 5 november 2003 13:55
To: [EMAIL PROTECTED]
Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard
Poetz a écrit :
...I'm +1 with the idea to send pages without payload but -0 with flowscripts which terminate without calling sendPage*. I would prefer an explicit way
Same here: flowscripts should not hide the fact that a response is indeed sent.
I suggested on the other thread that we could use "return null" as a signal for that.
function put() {
doput();
setStatus(201);
return null;
}
Null would mean a pipeline is not required to be executed.
-1 : we must have an explicit call to an environment-related method that
allows to detect if the application tries to send content back
afterwards. And this should not be available only in the flow as we may
want to do the same in an action.
That's why I proposed a redirect to a special "null" pseudo-protocol, as
once a redirect has been set the sitemap engine stops further processing
(unless it's a "cocoon:" redirect). But this may not be the cleanest way
and we may better use a method on the response object. And if
sendStatus() and sendError() don't fit, let's do our own
sendEmptyResponse(int status, String message).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
>
> -Original Message-
> From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
> Sent: woensdag 5 november 2003 14:29
> To: [EMAIL PROTECTED]
>
> Unico Hommes wrote:
> >
> >
> >
> >>-Original Message-
> >>From: Gianugo Rabellino [mailto:[EMAIL PROTECTED]
> >>Sent: woensdag 5 november 2003 14:02
> >>To: [EMAIL PROTECTED]
> >>
> >>Stefano Mazzocchi wrote:
> >>
> >>
> setStatus' friends the sendError brothers are also be
> eligible for
> FOM membership. But this change has a dependency on the
> discussion
> about bodyless responses since if you'd do a sendError
> from a flow
> script and then send a page afterwards this would result
> in errors.
> >>>
> >>>
> >>>I dislikde "sendError" because, in fact, HTTP does not have the
> >>>concept of errors, but only status codes and empty-payload
> >>
> >>responses.
> >>
> >>>In the future, it's entirely possible to have a 309 or
> >>
> >>equivalent that
> >>
> >>>is not an error, but has a empty-payload response. I would
> >>
> >>dislike to
> >>
> >>>call "sendError()" to send something that is not an error,
> >>
> >>feels hacky.
> >>
> >>>I think the optimal solution is:
> >>>
> >>> 1) add response.setStatus() in FOM
> >>> 2) allow the flowscript to terminate without calling
> >>
> >>sendPage* [thus
> >>
> >>>resulting in an empty payload]
> >>
> >>Sorry to jump in late, I'm probably lagging behind a few posts, but
> >>was the possibility of having *pipelines* send empty payload
> >>considered instead? This way flow will always have to
> sendPage(), but
> >>the result would be empty content anyway. With the added bonus of
> >>having the pipeline flexibility to, say, set headers.
> >>
> >
> >
> > But the function of a pipeline is specifically towards the
> production of
> > an xml response body. To have to set up all the components,
> execute the
> > pipeline and then fooling the pipeline to send its data to
> a null output
> > or refrain from pipeline execution altogether? In some
> scenarios that
> > may be necessary, for instance in the case of the http HEAD
> function.
> > The point is, you shouldn't have to, because there are a lot of
> > situations where its just unneccesary overhead. (for example all the
> > dummy responses in the davmap sitemap)
>
> I sure can see some use of this. In a few cases (think PUT) you might
> have XML input flowing through the pipeline (say you might want to
> transform it) yet you have to send an empty response: in this
> scenario
> using a pipeline looks like the best option to me.
Hmm, not to me. The way I have implemented PUT in the current davmap
differs from what you are suggesting.
Here I use two pipelines. One generates the request body:
The flow uses essentially the internal only request body generating
pipeline in a processPipelineTo type of construct:
Function put(in,out) {
var s1 = resolver.resolve(in);
var s2 = resolver.resolve(out);
cocoon.processPipelineTo(in.inputStream, out.ouputStream);
cocoon.response.setStatus(201);
// have to do:
cocoon.sendPage("dummy",{});
// but really want to do this:
// return null;
}
> Also, I
> feel that the
> sitemap is core and flow, while being core, is somehow
> "piggybacked" on
> the sitemap. I tend to think, then, that deciding whether to
> send output
> or not should belong more to the sitemap than to the flow.
>
The sitemap is always in control, we are talking about changing the
sitemap semantics in that a is extended so that it
can signal the sitemap to terminate processing the request. Maybe we
could add an attribute specifically allowing the function to not send a
page such as in but I
think this will only complicate things because now what happens if the
function does do a redirect? And what if we want to do what Vadim
suggested:
Function login() {
while(!loggedIn) {
sendPageAndWait("login");
loggedIn = ..
}
return {user:"user",message:"message"};
}
-- Unico
> Ciao,
>
> --
> Gianugo Rabellino
> Pro-netics s.r.l. - http://www.pro-netics.com
> Orixo, the XML business alliance - http://www.orixo.com
> (Now blogging at: http://blogs.cocoondev.org/gianugo/)
>
>
>
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Unico Hommes wrote: -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: woensdag 5 november 2003 14:02 To: [EMAIL PROTECTED] Stefano Mazzocchi wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Sorry to jump in late, I'm probably lagging behind a few posts, but was the possibility of having *pipelines* send empty payload considered instead? This way flow will always have to sendPage(), but the result would be empty content anyway. With the added bonus of having the pipeline flexibility to, say, set headers. But the function of a pipeline is specifically towards the production of an xml response body. To have to set up all the components, execute the pipeline and then fooling the pipeline to send its data to a null output or refrain from pipeline execution altogether? In some scenarios that may be necessary, for instance in the case of the http HEAD function. The point is, you shouldn't have to, because there are a lot of situations where its just unneccesary overhead. (for example all the dummy responses in the davmap sitemap) I sure can see some use of this. In a few cases (think PUT) you might have XML input flowing through the pipeline (say you might want to transform it) yet you have to send an empty response: in this scenario using a pipeline looks like the best option to me. Also, I feel that the sitemap is core and flow, while being core, is somehow "piggybacked" on the sitemap. I tend to think, then, that deciding whether to send output or not should belong more to the sitemap than to the flow. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
>
> -Original Message-
> From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
> Sent: woensdag 5 november 2003 13:55
> To: [EMAIL PROTECTED]
>
> Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard
> Poetz a écrit :
> > ...I'm +1 with the idea to send pages without payload but -0 with
> > flowscripts which terminate without calling sendPage*. I
> would prefer
> > an explicit way
>
> Same here: flowscripts should not hide the fact that a
> response is indeed sent.
>
I suggested on the other thread that we could use "return null" as a signal for that.
function put() {
doput();
setStatus(201);
return null;
}
Null would mean a pipeline is not required to be executed.
I've checked with Rhino. Null can indeed be used to discriminate between the situation
where you return nothing at all as in that case an Undefined object is returned to the
interpreter.
-- Unico
> -Bertrand
>
>
>
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
> > -Original Message- > From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] > Sent: woensdag 5 november 2003 14:02 > To: [EMAIL PROTECTED] > > Stefano Mazzocchi wrote: > > >> setStatus' friends the sendError brothers are also be eligible for > >> FOM membership. But this change has a dependency on the discussion > >> about bodyless responses since if you'd do a sendError from a flow > >> script and then send a page afterwards this would result in errors. > > > > > > I dislikde "sendError" because, in fact, HTTP does not have the > > concept of errors, but only status codes and empty-payload > responses. > > > > In the future, it's entirely possible to have a 309 or > equivalent that > > is not an error, but has a empty-payload response. I would > dislike to > > call "sendError()" to send something that is not an error, > feels hacky. > > > > I think the optimal solution is: > > > > 1) add response.setStatus() in FOM > > 2) allow the flowscript to terminate without calling > sendPage* [thus > > resulting in an empty payload] > > Sorry to jump in late, I'm probably lagging behind a few > posts, but was the possibility of having *pipelines* send > empty payload considered instead? This way flow will always > have to sendPage(), but the result would be empty content > anyway. With the added bonus of having the pipeline > flexibility to, say, set headers. > But the function of a pipeline is specifically towards the production of an xml response body. To have to set up all the components, execute the pipeline and then fooling the pipeline to send its data to a null output or refrain from pipeline execution altogether? In some scenarios that may be necessary, for instance in the case of the http HEAD function. The point is, you shouldn't have to, because there are a lot of situations where its just unneccesary overhead. (for example all the dummy responses in the davmap sitemap) Unico > WDYT? > > -- > Gianugo Rabellino > Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML > business alliance - http://www.orixo.com > (Now blogging at: http://blogs.cocoondev.org/gianugo/) > > >
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Stefano Mazzocchi wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Sorry to jump in late, I'm probably lagging behind a few posts, but was the possibility of having *pipelines* send empty payload considered instead? This way flow will always have to sendPage(), but the result would be empty content anyway. With the added bonus of having the pipeline flexibility to, say, set headers. WDYT? -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
Le Mercredi, 5 nov 2003, à 13:11 Europe/Zurich, Reinhard Poetz a écrit : ...I'm +1 with the idea to send pages without payload but -0 with flowscripts which terminate without calling sendPage*. I would prefer an explicit way Same here: flowscripts should not hide the fact that a response is indeed sent. -Bertrand
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
From: Stefano Mazzocchi > On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote: > > > setStatus' friends the sendError brothers are also be > eligible for FOM > > membership. But this change has a dependency on the > discussion about > > bodyless responses since if you'd do a sendError from a flow script > > and then send a page afterwards this would result in errors. > > I dislikde "sendError" because, in fact, HTTP does not have > the concept > of errors, but only status codes and empty-payload responses. > > In the future, it's entirely possible to have a 309 or > equivalent that > is not an error, but has a empty-payload response. I would dislike to > call "sendError()" to send something that is not an error, > feels hacky. > > I think the optimal solution is: > > 1) add response.setStatus() in FOM > 2) allow the flowscript to terminate without calling > sendPage* [thus > resulting in an empty payload] I'm +1 with the idea to send pages without payload but -0 with flowscripts which terminate without calling sendPage*. I would prefer an explicit way. I think this has advantages when you want to learn what a script does and I have the feeling that an implicit sending of HTTP headers can fool you if you have to debug your scripts. -- Reinhard
RE: [Vote] empty HTTP responses [was Re: Cannot easily set http status]
> > -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: woensdag 5 november 2003 12:42 > To: [EMAIL PROTECTED] > > > On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote: > > > setStatus' friends the sendError brothers are also be > eligible for FOM > > membership. But this change has a dependency on the > discussion about > > bodyless responses since if you'd do a sendError from a flow script > > and then send a page afterwards this would result in errors. > > I dislikde "sendError" because, in fact, HTTP does not have > the concept of errors, but only status codes and > empty-payload responses. > The only thing is that sendError method allows to set a message as well, whereas the setStatus equivalent for that has been deprecated as of servlet spec version 2.1 . According to the servlet spec there is another difference between sendError and setStatus. From the HttpResponse.sendError() api doc entry: "After using this method, the response should be considered to be committed and should not be written to." For setStatus this is not specified. Is there no way to set a response message and not commit the response at the same time? How can we fake this? > In the future, it's entirely possible to have a 309 or > equivalent that is not an error, but has a empty-payload > response. I would dislike to call "sendError()" to send > something that is not an error, feels hacky. > > I think the optimal solution is: > > 1) add response.setStatus() in FOM > 2) allow the flowscript to terminate without calling > sendPage* [thus resulting in an empty payload] > > Vote? > +1 > -- > Stefano. > > >
[Vote] empty HTTP responses [was Re: Cannot easily set http status]
On Wednesday, Nov 5, 2003, at 12:19 Europe/Rome, Unico Hommes wrote: setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. I dislikde "sendError" because, in fact, HTTP does not have the concept of errors, but only status codes and empty-payload responses. In the future, it's entirely possible to have a 309 or equivalent that is not an error, but has a empty-payload response. I would dislike to call "sendError()" to send something that is not an error, feels hacky. I think the optimal solution is: 1) add response.setStatus() in FOM 2) allow the flowscript to terminate without calling sendPage* [thus resulting in an empty payload] Vote? -- Stefano.
RE: Cannot easily set http status
> > -Original Message- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: woensdag 5 november 2003 0:12 > To: [EMAIL PROTECTED] > > > On Tuesday, Nov 4, 2003, at 14:21 Europe/Rome, Unico Hommes wrote: > > > > > Working on davmap I noticed that the way I was setting the > status code > > in the Serializer wasn't working. This is what I do: > > > > > > > > > > > > But it seems that the status-code attribute is not being > resolved. I > > propose we change this. > > -1, don't know but I don't like this. should be in the fom as > you propose below. > Yes I guess the use case is not a valid argument for making the attribute variable resolved. > > Then I thought I may be able to set it on fom response > object in the > > flow. But this too seems not to be possible. However, changing this > > seems to be a little more straightforward since setStatus is not a > > method on the environment Response interface but on the > HttpResponse > > implementation instead. I propose we add this method to the fom and > > make it a nop in case we are dealing with a different Response > > implementation than HttpResponse. > > +1 > setStatus' friends the sendError brothers are also be eligible for FOM membership. But this change has a dependency on the discussion about bodyless responses since if you'd do a sendError from a flow script and then send a page afterwards this would result in errors. > > > > > > Thoughts? > > > > -- Unico > > > > > -- > Stefano. > > >
Re: Cannot easily set http status
Unico Hommes wrote:
Working on davmap I noticed that the way I was setting the status code
in the Serializer wasn't working. This is what I do:
But it seems that the status-code attribute is not being resolved. I
propose we change this.
Within Lenya I use the status-code attribute as follows
(src/webapp/lenya/pubs/blog/webdav.xmap)
which works, but maybe the problem is the {1}
HTH
Michi
Then I thought I may be able to set it on fom response object in the
flow. But this too seems not to be possible. However, changing this
seems to be a little more straightforward since setStatus is not a
method on the environment Response interface but on the HttpResponse
implementation instead. I propose we add this method to the fom and make
it a nop in case we are dealing with a different Response implementation
than HttpResponse.
Thoughts?
-- Unico
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: Cannot easily set http status
On Tuesday, Nov 4, 2003, at 14:21 Europe/Rome, Unico Hommes wrote: Working on davmap I noticed that the way I was setting the status code in the Serializer wasn't working. This is what I do: But it seems that the status-code attribute is not being resolved. I propose we change this. -1, don't know but I don't like this. should be in the fom as you propose below. Then I thought I may be able to set it on fom response object in the flow. But this too seems not to be possible. However, changing this seems to be a little more straightforward since setStatus is not a method on the environment Response interface but on the HttpResponse implementation instead. I propose we add this method to the fom and make it a nop in case we are dealing with a different Response implementation than HttpResponse. +1 Thoughts? -- Unico -- Stefano.
