At 15:39 09/02/2001 +0100, you wrote:
>Raphaël Luta wrote:
>
>>We already decided on a stream oriented API so the choice can be
>>restricted to :
>>- char/byte streams
>>- SAX event streams
>
>A DOM oriented portlet could make use of a utility class to convert DOM
>into SAX (already there in most SAX parsers)
Yes, converting static -> stream structures (either DOM -> SAX or buffers
-> streams) is
easy to do and there are already a lot of utility code for doing this.
>>If the byte stream is chosen as the default communication medium between
>>the portlet and the portal, we will have:
>>if portlet natively generates byte streams :
>>- optimal performance when the portal does not need to post-process output
>>- degraded performance when the portal needs to post-process the output
>> (parsing byte stream)
>>if portlet natively generates XML events :
>>- slightly degraded performance when the portal does not need to post-process
>> output (event stream -> byte stream conversion)
>>- very degraded performance when the portal needs to post-process output
>> (event -> byte conversion and then reparsing by the portal)
>>If SAX stream is the default communication with the portal:
>>if portlet generates byte streams :
>>- very degraded performance if the protal does not post-process (byte ->
>>SAX, then
>> SAX -> byte)
>>- degraded performance (parsing byte -> event) when the portal postprocess
>> the events
>>if portlets generates SAX events :
>>- slightly degraded perf when no post-processing (event -> byte
>>serialization)
>>- optimal performance when post-processing (already parsed)
>>As you can see depending on your expected portal behavior and portlet
>>development
>>tools/methodology, either byte streams or SAX streams are the optimal choice.
>>So my proposal for the Portlet API is :
>>* add a getContentHandlet() method in the PortletResponse interface so
>>that a portlet
>> that wishes so can directly output events to the portal event handler.
>
>Don't forget getLexicalHandler() I think it is the only way to manage
>CDATA and entities.
You're right, getLexicalHandler() is also needed.
>>* allow the portlet either to use getWriter() or getContentHandler() but
>>not both (mutually
>> exclusive use just like ServletResponse.getWriter() and
>> getOutputStream()).
>
>In case of portlets that use SAX, I have the name SAXlets (c) Santiago
>Gala 2000. Look in the archives for the post where I copyrighted the name
>implicitly last year :) These methods could be put into servlet API, and I
>think they should. Something like an interface javax.servlet.sax.SAXlet.
>Servlets implementing this interface can be REQUESTED by the container to
>use getContentHandler and forbidden to use getWriter/getOutputStream. This
>again (c) Santiago Gala 2001. Feel free to quote it, since it is under
>Apache license.
Sorry to break your copyright, but this structure has already been proposed
by Assaf Arkin
as XMLServlet extension of the servlet API ;-)
You can find it in Castor.
That probably means it's a good idea :)
>>That way, it's the portal implementation of the PortletResponse which
>>will decide which
>>is the most efficient way to output data (depending on the whether the
>>implementation
>>parses the char stream into an event stream, serialize the event stream
>>into a char stream
>>or tries to handle natively both).
>>Does that sound reasonable ?
>+1024. I see you have put all my current thinking e-black on e-white. I
>think Thomas misunderstood my previous post, but this was exactly what I meant.
If you want a good laugh provided by our friends at Xo3:
http://www.portletsapi.org/
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
