Raphaël Luta wrote:
> 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
+1. That is what I was trying to say in my previous post.
>
> 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)
>
> 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.
>
> * 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.
>
> 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.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
