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.
----- Original Message -----
From: "Santiago Gala" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Friday, February 09, 2001 15:39
Subject: Re: Secure Portlets
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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
