At 22:04 12/02/2001 +0100, you wrote:
>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.
I think this is where we diverge: the issue at hand is whether we try to create
a generic Portlet API which may fit very different model or whether we do an
optimized version of the portlet API for our planned 1.3 implementation.
You'd like to limit the API to only methods that would be useful for our
implementation. I'd like to extend it to fit an possible alternate model.
><snip>
>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.
The inclusion of SAX calls is completely unrelated to performance (what will
impact the performance is if we require full documents rather than fragments)
>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.
Your implementation is optimized for speed at the cost of markup robustness.
Your have no guarantee that another implementation will accept the exactly
same document fragments that your portlets produce.
>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 ?
Yes. It's a tradeoff between robustness and performance.
In your portal implementation, you chose performance. In Jetspeed 1.3, we
may chose the same but we would be very short-sighted if we don't provide
the API for writing other implementations with other design goals.
>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.
Of course (although SAX is memory efficient).
Are you aware of other projects that try to create a generic
cross-implementation
portlet API ?
You can't say to a portlet developper in one hand:
we provide you with a generic API, you just need to write you portlet
against our API
and it will run correctly on whatever portal implementation supports this API
and on the other hand:
you need to taylor portlet output for each portal you're deployed on.
I think there's a contradiction somewhere.
>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.
Personally I don't mind tying the API to JAXP/SAX.
For me the issue is this:
Your API is efficient and perfectly fits your need and design requirements
but does not cover some of *my* requirements for an portal implementation
(not Jetspeed 1.3 but another project) based on SAX.
If the API does not cater for this need, my only logical conclusion is that I
need another API to suit my design requirements.
I really can't see any justification for not including the SAX API in the
Portlet
API if we aim to create a standard API.
Now the choice of full documents/fragments has a definite performance
impact (whether it's based on byte stream or SAX) so this is a decision that
should carefully weighted and considered.
--
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]
