At 18:44 12/02/2001 +0100, you wrote:
>At 14:12 02/12/01, Raphaël Luta wrote:
>>Following the discussions on the Portlet API, there's no strong consensus
>>on the following points of the Portlet API and so they should be voted upon.
>>
>>For those who did not follow the arguments, pleae read the "Secure Portlets"
>>thread in the mail archive before voting.
>>
>>Point 1:
>>Should the Portlet API mandate that portlet only output full documents rather
>>than document fragments ?
>
>I don't really get this point. How could portlets output full documents,
>doesn't it always have to be a fragment? Or are you thinking in XML
>documents that are stripped don to fragments later? Sorry, I really don't
>undersand this point.
See my response to Santiago and David. I think it's very important to
conciously decide
on this point and not rely a what is done currently.
>>Point 2:
>>Should we add a getContentHandler() and getLexicalHandler() in the
>>PortletResponse interface ?
>>A portlet will not be able to use both getWriter() and getContentHandler()
>>in the same request response.
>
>I share the demurs of Thomas: Sax and XML is very popular at the moment,
>but most general are still streams. I'm not sure if it's wise to open the
>door for specialized ways of content passing: What if other "standards"
>want their own interface too, what if the Sax interface changes (it did
>change often in the past!).
I think the SAX API is pretty stable now and is a good choice for handling
"high level" communication
between portal and portlet if the portal implementation supports it.
>This would really put the stability of out portal API at a risk. The
>problem is that once those methods are in the interface and portlets are
>programmed against it, we are dammed to support them in the engine if we
>don't want to scare the people away from the portlet interface.
Sure, but the implementation is trivial if you don't want to do high level
communication.
>The alternative - not quite as nice, but still good - is to do all
>processing on the portlet side of the API: A Saxlet could take the XML
>output of the SaxPortlets, do all necessary processing, and produce a
>markup stream. This is really stupid if you want to postprocess the
>aggregated page on the other side of the API, in the portal engine, I
>agree with you. Yet, the question for me is: is there really a need for
>doing so?
First the SAXlet approach does not work, unless you hardcode a "SAXlet" for
your portal implementation and
expose to this SAXlet all your implementation functionalities. What this
means basically is that you
reimplement a portal within the context of the Portlet API. This makes no
sense.
Second, post-processing can occur both before aggregation (post-processing
of the portlet output) and after
aggregation (post-processing of the complete portal output). The SAXlet
approach is stupid for the first
case and is irrelevant for the second case since if you post-process the
aggregate result you have to
buffer the complete aggregation result however you produce it.
Now if the question is; is postprocessing required ?
My answer is: it's a portal implementation decision (unless we chose to
restrict full doucment output
for portlets in which case the answer would always be yes)
If the question is: is there a need for a SAX interface ?
My answer is: yes, because some portal implementations may have different
design goals that optimizing
for speed and SAX will certainly the best API for high level communication
and processing between portlet
and portal.
>So I think Point 2 is better fomulated as:
>"Is there a requirement for postprocessing the whole portal page in the
>servlet engine after the aggregation (alternativ 1) or is it sufficient to
>take the XML and convert it into markup on the portlet side of the API
>(alternative 2)?"
>With alternative 1 there is the danger of making the portlet API more
>complicated and (that's important!) *less stable*.
>
>Is this a fair way of putting it?
No, you completely miss the point.
Providing SAX methods in the API just enables high level communication
between Portal and
portlets if the portal implementation wants it this way. It give the
freedom to portal developers
to chose whatever level of post-processing they like and still have an
optimized way to
communicate with the portlet.
It does not impact the performance of native stream based portal and
portlet implementations.
It *does not* imply any implementation constraint for the portal (apart
from the implementation
of a trivial SAX->byte stream serializer).
Also, SAX is at least as stable as the Servlet API.
SAX and post-processing are 2 independant issues. Post-processing is
decided by the
portal implementor (but if you chose to implement a lot of post-processing,
using the SAX
streams rather than the byte streams will probably be more efficient)
--
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]
