Re: autoflush behavior for subrequests

Subrequests are not well defined in general. They sit somewhere in the 
nether region between component calls and separate requests, and 
everyone expects something a little different from them. :)

Without a really detailed definition of what subrequests are supposed to 
do by default, I'm afraid that every "bug" we fix for one person will 
cause another "bug" for someone else. So let's not make any changes to 
subrequest behavior in the stable branch unless they are *completely* 
uncontroversial, and try to revamp things in the next release. I'm not 
sure where that leaves your current bugfix (haven't had time to study it 
closely).

That said...

In my experience, most people use subrequests for "internal redirects", 
and this is how they expect (or would like) them to work:

1. Any current contents of the parent buffer are cleared.
2. The out_method of the subrequest is the same as the out_method of the 
parent.
3. autoflush or manual flush_buffers take effect immediately.
4. If the subrequest returns successfully, the parent aborts (so as not 
to generate any more output) with the return value (if any) of the 
subrequest.
5. If the subrequest aborts, the parent aborts with the aborted value.
6. If the subrequest dies with an error, the error gets handled in the 
same way as if the parent had generated it.

Perhaps we should have a $m->internal_redirect() that uses $m->subexec() 
underneath but guarantees the above behavior.

Other people try to use subrequests as mere glorified component calls 
with dhandlers and autohandlers turned on. (This seems rarer because, 
for one thing, you've got to deal with the double content wrapping 
problem.) Because this use case is less frequent, we don't have to worry 
as much about the default subrequest behavior supporting it.

Jon

Dave Rolsky wrote:

> So in fixing a bug related to this I realized that there are cases where
> the behavior of a subrequest with autoflush (or when it calls
> flush_buffer) really isn't well defined.
> 
> There are two questions to consider:
> 
> 1. Should a subreauest which calls $self->flush_buffer be flushing the
>    parent request?
> 
> Right now it does, but I'm not sure that's right.  Maybe the subrequest
> should really be isolated if the parent does not have autoflush on.
> 
> 2. Given a parent with autoflush on, and a subreq which explicitly turns
>    it off, what do we expect to happen?  Right now the output gets flushed
>    anyway, because the child's default out_method will end up calling
>    print() on the parent, which will then flush.
> 
> Is this correct?  Again, if the subrequest should be totally isolated then
> it's not correct.
> 
> 
> The fix for these would be to not call print() on the parent from the
> subrequest.  Instead we'd have to ignore out_method for subrequests, and
> just have their first buffer be a child of the parent object's last
> buffer.
> 
> 
> -dave
> 
> /*===========================
> VegGuide.Org
> Your guide to all that's veg.
> ===========================*/
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Mason-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mason-devel
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php