At 13:10 08/02/2001 +0100, you wrote:
>Raphael,
>
>I think I do understand what you mean.
>
> > "Well-formed XML" simply implies that the output of the portlet will be
> > parseable by an XML parser but does not enforce (or even expect) any
> > DTD or schema compliance.
>
>How on earth do you want to write a parser for a language that you don't
>know. Leaving out the DTD only means that the portlet is not technically
>bound, it would still need to compliant to some language. Unless --- unless
>you are talking about different parsers for mime-type which the aggregation
>module may be to handle.
Even if the API does not mandate a DTD compliance, in order to aggregate and
post-process the documents the portal will always assume that the portlet
will output a known format (XHTML, WML, etc...). However this a portal
implementation issue.
>But then, parsing the markup - even if it was well-formed - is an expensive
>operation. I don't think we should enforce this burden onto the portal just
>because we are not able to provide utility functions to do link substitution
>in place (that is, right in the template). Also, you cannot leave this
>decision open, because a portlet that relies on the portal to do certain
>substitions would not run properly on a portal that goes for performace and
>leaves everything through.
>
>I think this discussion is crucial to the future of Jetspeed. Looking
>forward to more arguments...
It is a very important choice.
I agree that parsing may be an expensive operation (although I believe SAX
parsing
is quite efficient) but, since I base my reasoning on the premise that in
80% of the
requests, the portal will *have* to parse the result in order to aggregate
correctly the
portlet output, it's a cost that we'll encounter in most case and that we
should try to
minimize.
The portlet to portal communication can be done through
- streams
- SAX events
- string buffers
- DOM tree
We already decided on a stream oriented API so the choice can be restricted
to :
- char/byte streams
- SAX event streams
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.
* allow the portlet either to use getWriter() or getContentHandler() but
not both (mutually
exclusive use just like ServletResponse.getWriter() and getOutputStream()).
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 ?
--
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]
