At 23:56 13/02/2001 +0100, you wrote:
>I think it is useful to provide a little summary of the current state of
>the discussion.
>I tried to give a neutral summary on each item, followed by my opinion.
Thomas, I think it's a very good summary of the issues.
I have just 2 things to add/modify to this.
- Point 1 should be titled:
"Should the Portlet API require portlets to produce full documents ?"
Wer're not discussing (yet) the Jetspeed implementation, which may
support both full documents and document fragments through
configuration elements external to the proposed standard Portlet API
(for example the portlet deployment descriptors that were proposed in
the first Portlet API discussion 3 months ago)
- I think we should add to this summary the following notice:
The Jetspeed community has decided to start specifying a portlet API
that could be proposed as a standard for all portal implementations.
Offering a standard API between portals only makes sense if the portals
implementing the API can guarantee to the portlet writers complying to
this API that their portlet will always run correctly whatever the
implementation they are deployed upon: "write once, deploy anywhere"
This is the reason why the Portlet API should define both the
programmatic API as such, but also the content guidelines that
portlet writers should follow to achieve portability and possibly the
deployment process.
>Point 1: Should JetSpeed require portlets to produce full documents ?
>
>Producing full documents means that the portal implementations would need
>to decide which parts of complete documents returned by portlets should
>actually be embedded in the overall page created by the portal.
>
>The motivation behind this - as Raphael described it - is that there are no
>guidelines defined for fragments that should be returned by portlets for
>markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the guideline
>for portlet developers should be "Portlets must output well-formed
>(complete) documents conforming to the DTDs required by the client devices"
>instead of "Portlets should return well-formed document fragments suitable
>for aggregation in well formed documents conforming to the DTDs required by
>the client devices".
>
>The result of JetSpeed requiring portlets to produce full documents would
>be that all content generated by portlets would need to be post-processed
>by the portal implementation. There seems to be agreement that this
>introduces significant performance and memory overhead compared to portlets
>directly writing fragments to the portlet output stream without
>post-processing. There is disagreement on whether the resulting performance
>and memory overhead is acceptable or not.
>
>(My Opinion (TS): We have implemented a portal that serves HTML, WML,
>VoiceXML and cHTML. The portlets directly write mark-up fragments to the
>output stream using JSPs or Stylesheets without post-processing, which is
>very fast. Forcing all content to be post processed through a SAX parser
>would impose an unacceptable performance degradation on our portal. We can
>make guidelines for content fragments that should be created by portlets
>available to resolve the issue of missing guidelines.
>My opinion is that we should under no circumstances require complete
>documents to be returned by portlets, as this woud introduce an inherent
>limitation of JetSpeed's performance.)
>
>
>Point 2: Should the Portlet API provide dedicated methods for SAX output ?
>
>This means that the methods getContentHandler() and getLexicalHandler()
>would be added to the PortletResponse interface.
>
>The motivation behind this is that it should be possible for portlets to
>output SAX events rather than writing to the output stream so that portal
>implementations that internally process SAX events can provide document
>handlers that would directly be invoked by portlets rather than parsing the
>portlet response's output stream to create SAX events.
>
>The result of the JetSpeed Portlet API defining the SAX specific methods as
>part of the core API would be that the Portlet API depends on the
>org.xml.sax package (JAXP). The SAX specific methods are unlikely to be
>accepted as part of a prospective Portlet API standard. Adding the SAX
>methods would de-facto separate portlets into two kinds - portlets writing
>to the output stream and portlets sending SAX events. Portal
>implementations would have to be able to run both kinds of portlets, a
>stream based portal implementation would need to provide an impementation
>of PortletResponse that receives the SAX events from "SAX Portlets" and
>writes the content to the output stream, a SAX based portal implementation
>would need to parse the content written to the portlet's output stream by
>"Stream Portlets" to create appropriate SAX events. This seems technically
>feasible, but there is disagreement on whether the SAX methods are
>appropriate for a standard Portlet API or not.
>
>(My Opinion (TS): Although it seems technically feasible, we should not add
>the SAX methods to the Portlet API. The Portlet API should be designed as a
>standard API like the Servlet API, and like the Servlet API it should not
>contain specific methods dedicated to specific methods of creating output,
>be it SAX, DOM, ...)
--
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]
