Re: Optimising #include creation of FastWriter

On Thu 9 March 2006 17:00, Endre Stølsvik wrote:
> On Wed, 8 Mar 2006, Eric B. Ridge wrote:
> | I've been thinking back to when I write IncludeDirective and I simply
> | cannot remember why it makes a new FastWriter.  Was it because the old
> | ParseDirective did that and I was just coping it?  Was it out of sheer
> | stupidity?  Or maybe some reason about not wanting to muck with the real
> | FastWriter in the event of a parsing/evaluation exception.  I dunno.
>
> You should have commented it in the code.
>
> ..
>
> One comment about the FastWriter/Writer thingy: A "resetable" writer would
> be fantastic, preferrably having unlimited resetable space (just growing
> adding byte-arrays into some list as needed).
>   I am responsible for a portal, which renders every portlet in its own
> context and with its own "StringWriter", so that if it throws an
> exception, I can throw it away, and instead render an error-portlet. If
> all goes well, I commit the fully rendered portlet to the FastWriter, and
> move along.
>
> However, this would be hugely better if I could just _always_ pass along
> the same fastwriter recursing down includes and macros and whatnots.
> Before I venture into the next portlet, i do a mark(). Then I let it
> render the portlet, with its recursing. Then if an exception turns up,
> I'll just do a reset(), and then output an error-template instead, while
> if it goes well, i'll do a _flush()_ to commit the stuff all the way to
> the browser at the other end of the stream (I feel this should be up to
> me, the webapp writer, to decide when to flush). That would have been
> absolutely great, and absolutely more performant.

It's not going to be extending FastWriter because after a cursory look at the 
code it appears to be caching small (<4k blocks) of binary data in the 
FastWriter and then pushing them out to the underlying OutputStream whenever 
it needs to get it's internal buffer into some kind of known state.

Therefore if it had already pushed data out to the OutputStream when you tried 
to rollback your code to the last point then it would fail because it would 
no longer have access to or control of the data.

To do this properly you would need to maintain a single data structure that 
holds the entire contents of whatever is written to it in memory and then 
shifts it out once you've satisfied yourself that it isn't going to need to 
rollback.

I don't think that you are going to do this by extending FastWriter - it just 
doesn't feel right.  Unfortunately great chunks of WebMacro are expecting 
FastWriter as their target output stream so at present you are kind of 
stumped.  Might be interesting to look at what the difference is between 
Writer and FastWriter and refactor the calling code if it is not too much 
hassle?

However, the more I think about it, the more I feel that this "rolling back" 
is not a nice idea, for the following reasons:-

- the success / failure thing should be a javaspace thing and to only have it 
occur inside the middle of a portlet feels a bit odd to me.  I kind of feel 
that when the portlet rendering template is invoked, that the context should 
already contain a set of calculated portlets (or error portlets) that reflect 
the state of the system.  Then the rollback is just not necessary.

- rolling back the output is only half of the problem.  webmacro code can make 
changes to the state of the backend java system and to the state of the 
context.  Just because you roll the output stream back doesn't mean that the 
java and context are in any way in a consistent state with what they were 
before the rollback point.  To imply that they are is just tempting fate...

Just out of interest - how were you envisioning this rolling back happening?  
Was it going to be a java space action or would it take place during the 
template rendering phase?

Alex


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642