Raphael,
I think we should not decide on these two points as isolated items, they
need to be put into perspective to make sure that everybody fully
understands the consequences and implications before voting. The larger
question behind this is whether we want JetSpeed to be a high-performance,
highly scalable portal engine usable for portals under a high load or
whether we are willing to accept mediocre/poor performance/scalability
which would inhibit use of JetSpeed in larger projects that need high
performance and scalability. There will be more design decisions where we
have to choose between performance/scalability/reliability on one side and
something convenient, something nice or cool on the other side and these
decisions will depend to a certain extent on our answer to the more
fundamental question raised above.
I think we should decide for the first option so that JetSpeed gets the
chance to evolve into industry strength software like the Apache HTTP
Server.
To give you an example, our portal implementation uses JSPs or to generate
all output, portlets may use JSPs or stylesheets, everything is written
directly to the servlet's output stream, we have reduced per-request memory
usage and per-request processor usage as far as possible to achieve the
required performance and scalability. We have no need for any kind of
post-processing, as our portlets create appropriate markup-fragmentsa and
dynamic URL lookup within JSPs entirely avoids the need of URL
postprocessing.
If the vote on point 1 would be yes, this would result in severe
performance problems: If the portlet API mandates full documents, this
would require costly post-processing to strip off parts during content
aggregation. It is much more efficient to have each portlet write a
document fragment to the output stream at the appropriate point in time
during page aggregation than to have each portlet create a complete
document in the form of SAX events, send all these events to a document
handler that drops the parts that are not required and finally writes the
relevant parts to the output stream. Did you measure by which factor the
SAX parsing will reduce performance and increase memory usage per request
compared to straight JSP processing ?
Even if there would be post-processing, portlets could still screw the
entire portal by producing large amounts of valid XML, producing
well-formed but invalid XML (e.g. invalid WML), or using up the JVMs
memory. In all portal projects I have seen so far, portlets were tested
before they were deployed and it was the responsibility of the portlets to
produce correct mark-up.
The introduction of a getContentHandler() method to the Portlet interface
seems like a compromise that would allow for the SAX approach in addition
to the stream-based appropach, but it would force all portal container
implementations to implement both mechanisms and it would introduce a
direct dependency of the portlet interface and thus the Portlet API to the
interface org.xml.sax.DocumentHandler. Of courcse the org.xml.sax package
will become a part of J2EE 1.3, but nonetheless I think the Portlet API
should not depend on the XML API, it should only depend on core java
classes as it currently does. As we intend to turn the Portlet API into a
standard, we should not add special methods for such specific tasks as
doing SAX event handling.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail:
[EMAIL PROTECTED] Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany
------------------------------------------------------------------------------
Raphael 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 ?
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.
--
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]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
