Raphael Luta wrote:
> At 23:56 13/02/2001 +0100, you wrote:
>
> >I think it is useful to provide a little summary of the current
> >state of the discussion.
> >I tried to give a neutral summary on each item, followed by my
> >opinion.
>
> Thomas, I think it's a very good summary of the issues.
>
> I have just 2 things to add/modify to this.
>
> - Point 1 should be titled:
> "Should the Portlet API require portlets to produce full documents ?"
Yes, that's a better title, we are actually talking about the Portlet API
here.
>
> Wer're not discussing (yet) the Jetspeed implementation, which may
> support both full documents and document fragments through
> configuration elements external to the proposed standard Portlet
> API (for example the portlet deployment descriptors that were
> proposed in the first Portlet API discussion 3 months ago)
The document fragments need to be in the standard and the full documents
need to be prohibited by the standard (see below).
This not only my opinion, but also what our customers and other portal
vendors I already talked to about Portlet API standardization are saying.
If you look at the web sites of Oracle, BEA, and other portal vendors, you
will see that they are also using document fragments
(see also Ingo Rammer's note listing Oracle's guidelines).
We'd hardly find a single major portal vendor who would be in favour of
requiring full documents in the standard that require mandatory
post-processing that will slow down his implementation and lead to bad
benchmark results.
Just today I visited a very large portal customer at their headquarters
and talked to their technical experts and technical decision makers the
whole day. One topic was of course aggregation and they were very happy
with the approach to use portlets that write document fragments directly
to the output stream one after the other. They asked whether we would
create
temporary objects/strings or do any post-processing and were only satisfied
after I assured them that everything is written directly to the output
stream
without any performance or memory overhead. We cannot change this.
Ok, I guess now I've stressed this point more than enough ;)
>
>- I think we should add to this summary the following notice:
>
> 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 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.
I absolutely agree that content guidelines (or better rules) that portlet
programmers/designers must follow should be defined in addition to the
programmatic Portlet API.
I think these rules need to contain the following items:
* A general statement saying that portlets must return document fragments
suitable for aggregation in the client's expected mark-up language and
may not return full documents.
* Detailed Specs of Fragments for particular mark-up languages:
- A HTML Fragment Specification for Portlets
- A WML Fragment Specification for Portlets
- A cHTML Fragment Specification for Portlets
- A VoiceXML Fragment Specification for Portlets
- Fragment Specifications for other mark-up languages
We can provide the fragment specs for HTML, WML, cHTML and VoiceXML.
These specs along with the specification of the programmatic Portlet API
and the Portlet Archive format will enable "write-once, deploy everywhere"
for portlets.
Once these specifications are available, tools can be written that take
templates created by visual tools and strip off the tags before deployment
of portlets, rather than stripping off the tags at run-time in a
post-processing step for each request.
By the way, the rules we use for HTML fragments in our projects at IBM
are basically identical to Oracle's that Ingo Rammer has posted, I guess
it is just common sense that leads to these guidelines. The guidelines
for the other mark-up languages may be a little bit trickier, but certainly
doable.
>
> >Point 1: Should JetSpeed require portlets to produce full documents ?
> >
> >Producing full documents means that the portal implementations would
need
> >to decide which parts of complete documents returned by portlets should
> >actually be embedded in the overall page created by the portal.
> >
> >The motivation behind this - as Raphael described it - is that there are
no
> >guidelines defined for fragments that should be returned by portlets for
> >markups like (X)HTML, WML, SMIL, FO, VoiceXML, cHTML and that the
guideline
> >for portlet developers should be "Portlets must output well-formed
> >(complete) documents conforming to the DTDs required by the client
devices"
> >instead of "Portlets should return well-formed document fragments
suitable
> >for aggregation in well formed documents conforming to the DTDs required
by
> >the client devices".
> >
> >The result of JetSpeed requiring portlets to produce full documents
would
> >be that all content generated by portlets would need to be
post-processed
> >by the portal implementation. There seems to be agreement that this
> >introduces significant performance and memory overhead compared to
portlets
> >directly writing fragments to the portlet output stream without
> >post-processing. There is disagreement on whether the resulting
performance
> >and memory overhead is acceptable or not.
> >
> >(My Opinion (TS): We have implemented a portal that serves HTML, WML,
> >VoiceXML and cHTML. The portlets directly write mark-up fragments to the
> >output stream using JSPs or Stylesheets without post-processing, which
is
> >very fast. Forcing all content to be post processed through a SAX parser
> >would impose an unacceptable performance degradation on our portal. We
can
> >make guidelines for content fragments that should be created by portlets
> >available to resolve the issue of missing guidelines.
> >My opinion is that we should under no circumstances require complete
> >documents to be returned by portlets, as this woud introduce an inherent
> >limitation of JetSpeed's performance.)
> >
> >
> >Point 2: Should the Portlet API provide dedicated methods for SAX output
?
> >
> >This means that the methods getContentHandler() and getLexicalHandler()
> >would be added to the PortletResponse interface.
> >
> >The motivation behind this is that it should be possible for portlets to
> >output SAX events rather than writing to the output stream so that
portal
> >implementations that internally process SAX events can provide document
> >handlers that would directly be invoked by portlets rather than parsing
the
> >portlet response's output stream to create SAX events.
> >
> >The result of the JetSpeed Portlet API defining the SAX specific methods
as
> >part of the core API would be that the Portlet API depends on the
> >org.xml.sax package (JAXP). The SAX specific methods are unlikely to be
> >accepted as part of a prospective Portlet API standard. Adding the SAX
> >methods would de-facto separate portlets into two kinds - portlets
writing
> >to the output stream and portlets sending SAX events. Portal
> >implementations would have to be able to run both kinds of portlets, a
> >stream based portal implementation would need to provide an
impementation
> >of PortletResponse that receives the SAX events from "SAX Portlets" and
> >writes the content to the output stream, a SAX based portal
implementation
> >would need to parse the content written to the portlet's output stream
by
> >"Stream Portlets" to create appropriate SAX events. This seems
technically
> >feasible, but there is disagreement on whether the SAX methods are
> >appropriate for a standard Portlet API or not.>>
>
> >(My Opinion (TS): Although it seems technically feasible, we should not
add
> >the SAX methods to the Portlet API. The Portlet API should be designed
as a
> >standard API like the Servlet API, and like the Servlet API it should
not
> >contain specific methods dedicated to specific methods of creating
output,
> >be it SAX, DOM, ...)
>
> --
> 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]
