After the discussions we had during the last few days and
before the upcoming decision, I'd like to provide a new
summary of the current state of the discussion and explain
IBM's position in a separate section at the end, after the
dotted line.
We are all in agreement about our common goal :) - Raphael
has provided an excellent description of this goal:
"The Jetspeed community has decided to start specifying a
Portlet API that could be proposed as a standard for all
portal implementations.
Offering a standard API between portals only makes sense
if the portals implementing the API can guarantee to the
portlet writers complying to this API that their portlet
will always run correctly whatever the implementation they
are deployed upon: 'write once, deploy anywhere'
This is the reason why the Portlet API should define both
the programmatic API as such, but also the content guidelines
that portlet writers should follow to achieve portability and
possibly the deployment process."
There are open questions on how to realize this goal. I'd
like to ask everybody to spend an appropriate amount of time
to think through all the implications of all different
alternatives before we decide, including relation to the
Servlet API and XML APIs, acceptance of the Portlet API by
portal product vendors, induced development costs for portal
vendors, system complexity, performance and scalability, etc.
Three orthogonal issues (1-3) need a decision, after that, we
have to choose from several implementation options (4).
1.Primary output mode
(This affects the programmatic Portlet API)
Alternatives:
a) output stream as base mode in portlet package
sax as special mode in portlet.sax package
b) neutral base interfaces in portlet package
sax as special mode in portlet.sax package
output stream as special mode in portlet.stream package
c) sax as base mode in portlet package
output stream as special mode in portlet.stream package
Note: Whether or not portlets will run on all portlet
containers does not depend on the primary output mode or the
package structure of the API, but only on whether the
specification defines all output modes as mandatory or not.
When offering multiple output modes, the specification must
mandate implementation of all of them by all portlet
containers to assure portlet portability.
2.Fragments and/or Full Documents
(This affects portlet container performance and ease of
implementation - and thus development costs)
Alternatives:
a) only document fragments concatenatable without post-processing
-> high-performance
-> low effort implementation of portlet container
-> requires to strip off tags from tool-generated
document templates once in advance
-> container can easily concatenate portlet output
-> container can be agnostic to fragments' internal
structures
b) document fragments and full documents
-> high performance possible if programmers use fragments
-> higher effort for implementation of portlet containers
-> container must strip off tags from full documents
generated by some portlets at run-time and be able to
handle framents.
-> container must be aware of document structure and know
what parts have to be stripped off for each particular
markup type
c) only full documents that require post processing
-> lower performance
-> higher effort for implementation of portlet containers
-> container must strip off tags from documents generated
by portlets at run-time
-> container must be aware of document structure and know
what parts have to be stripped off for each particular
markup type
3.Internal structure of documents of fragments
a) only potential contents of tables, cards, etc.,
i.e. fragments could not contain multiple cards or pages
-> simple aggregation
b) potential content of tables, multiple cards, etc.,
i.e. fragments could contain multiple cards or pages or
card content
-> aggregation must be able to handle multiple cards/pages
returned by portlets
4. Implementation options
a) Streams/Fragments only
Simple, high-performance, highly scalable implementation
In advance
Runtime Runtime or on-the-fly
+--------+ ---> +-------------+ +----+
| | | Portlet |<-Fragent--| |<-Doc
| | <--- +-------------+ Template | | Template
| | ---> +-------------+ | |
| | | Portlet |<-Fragent--| |<-Doc
| Portal | <--- +-------------+ Template |Frag| Template
| Aggre | ---> +-------------+ |Tool|
| gation | | Portlet |<-Fragent--| |<-Doc
| | <--- +-------------+ Template | | Template
| | ---> +-------------+ | |
| | | Portlet |<-Fragent--| |<-Doc
+--------+ <--- +-------------+ Template +----+ Template
|
| Portlets write fragments
| directly to output stream
v
OutputStream
|
v
Client
Figure 1
b) Streams/Fragments *and* SAX/full documents
more complex, high-performance and highly scalability when
using streams/fragments, lower performance and lower
scalability when using SAX/full documents, both is
possible
In advance
Runtime Runtime or on-the-fly
+--------+ -> +-----------+ +----+
| | | Portlet |<-Fragent--| |<-Doc
| | <- +-----------+ Template |Frag| Template
| | -> +-----------+ |Tool|
| | | Portlet |<-Fragent--| |<-Doc
| Portal | <- +-----------+ Template +----+ Template
| Aggre | --------|-----> +-----------+
| gation | | | Portlet |<-----Doc
| | <-------|------ +-----------+ Template
| | --------|-----> +-----------+
| | | | Portlet |<-----Doc
+--------+ <-------|------ +-----------+ Template
| | |
| | | Sax Events
| | v
| | +-------------+
| | | Post | Post processing
| | | processing | must strip of
| | | Doc handler | parts of documents
| | +-------------+
| | |
| | v
+--------------+------>OutputStream
|
v
Client
Figure 2
c) SAX/full documents only
complex, lower performance, lower scalability
Runtime Runtime
+--------+ ---> +-------------+
| | | Portlet |<------------------Doc
| | <--- +-------------+ Template
| | ---> +-------------+
| | | Portlet |<------------------Doc
| Portal | <--- +-------------+ Template
| Aggre | ---> +-------------+
| gation | | Portlet |<------------------Doc
| | <--- +-------------+ Template
| | ---> +-------------+
| | | Portlet |<------------------Doc
+--------+ <--- +-------------+ Template
| |
| | Sax Events
| v
| +-------------+
| SaxEvents | Post | Post processing must
+---------->| processing | strip of parts of
| Doc handler | documents
+-------------+
|
v
OutputStream
|
v
Client
Figure 3
---------------------------------------------------------------
Explanation of IBM's position:
1. Primary output mode
IBM prefers option a), i.e. a compromise with streams as primary
output mode offered by portlet.PortletResponse and SAX events as
a secondary output mode offered by portlet.sax.SaxPortletResponse.
This is very similar to the Servlet 2.2/2.3 API, where a stream
can be obtained directly from ServletRequest.
Unlike the Servlet API, the Portlet API would additionaly
provide explicit SAX support in the sax package and introduce a
dependency on org.xml.sax, i.e. a separate package. Such a
dependency of an API package to another API package that is not
part of the core Java classes is rather uncommon.
IBM can accept option b) if necessary to reach a consensus,
i.e. a neutral base interface portlet.PortletResponse,
and the portlet.stream and portlet.sax packages with equal
emphasis. (See Ingo's comporomise proposal, but note that
whether or not portlets will run on all portlet containers
does not depend on the primary output mode or the
package structure of the API, but only on whether the
specification defines all output modes as mandatory or not.
When offering multiple output modes in the Portlet API, the
specification must mandate implementation of all of them by
all portlet containers to assure portlet portability..)
Option c) preferred by Raphael, i.e. SAX events as the
primary output mechanism in the package portlet and streams
as a secondary output mechanism in portlet.stream (see one
of Raphael's previous notes on the mailing list) is not
acceptable for IBM. I would expect this to require a change
for later Portlet API standardization.
Option c) would mean to ignore that the output stream is
the natural output mode to many people and the *only* one
supported by the Servlet API itself.
2. Fragments and/or full documents
IBM prefers option a), i.e. mandatory use of document fragments,
as it allows for fast implementations and keeps complexity and
thus development and maintenance costs low.
If it necessary for a consensus, we can accept option b) as a
compromise. i.e. allowing for both use of fragments *and* full
documents.
Option c), i.e. mandatory use of full documents that require
post-processing is not acceptable for IBM because of the major
performance impact of mandatory post-processing.
3. Internal structure of document fragments
We prefer option a), option b) can potentially be accepted
as a compromise if necessary, but requires more investigation.
b)would add significant complexity to portlet container
implementations, as they would need to merge multiple cards per
portet into portal stacks, keeping in mind the buffer limitations
of devices.
4. Implementation
Option a) is the most desirable implementation for the April
release from our point of view. Extension to b) is possible
in the following release.
Option b) is a possible compromise, but seems hardly achievable
for an April release of JetSpeed before ApacheCon.
Option c) is not acceptable for IBM.
Best regards,
Thomas
Thomas Schaeck
Portal Architect
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
