Thomas F. Boehme wrote:
> Santiago, Raphael,
>
> What's wrong with doing the things you suggested in a derived portlet?
> Because the stream is the final result you can map (virtually) any other
> method like SAX, DOM, ECS, etc to the stream. This way the interface is not
> complicated any further, and portlet container writers are not burdened with
> several implementation paths.
> Also, doing this in derived portlets, mean we can easily add other mechanism
> including Cocoon2 (so I think), without any modifications to the API! Sounds
> very appealing to me....
>
> Raphael,
>
> I disagree with your assumption that 80% of the portlet markup needs to
> parsed anyway. If that were so something is fundementally wrong. At any
> rate, Jetspeed 1.3a1 does not parse any of its generated markup for whatever
> reason, and it does what it is supposed to do.
>
> Cheers,
> Thomas B.
>
>
I think that the reason of offering this alternate API is that an Event
Stream is much higher level thant a Byte or Character Stream. It keeps
the information structure as far as possible inside the server. So, it
minimises information loss. And it is memory efficient, since processing
is synchronous and there should be no memory overhead. ByteStreams are
more efficient than XML Events, but lower level.
This is one of the best things I have found in Cocoon2 architecture. If
we believe Stefano when he said that XML is the new ASCII, then, we
should use ASCII streams ---> SAX streams whenever possible.
Once Cocoon2 integrates a SAX event caching mechanism (Ricardo is
working on it), we could use it to cache pre-parsed RSS portlets in a
memory efficient and fast way.
We are already supporting, in not yet public code, HTML and WML with the
same PSML file using a final media adapted XSLT transformation. All
portlets generate XML, and the aggregation process is a matter of
following the PortletSet structure and generating SAX events on the fly.
This events are processed by a final Stylesheet, that formats the
output. I think that the code is even simpler than the current code.
The solution that Raphaël explained is suitable for both worlds, has
little to no overhead when mixing both kinds of portlets. It could be
offered as optional, although you could quite simply offer a
ByteStreamContentHandler that just streams the events to the response
Writer as they come.
In the other case, offering a Writer that parses the received info into
a XMLReader is more expensive, but it should be, since we are getting
information from the stream.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
