At 23:04 14/02/2001 +0100, you wrote:
>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.
> >
> >
> > 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.
What you're saying is just that no vendor has yet tried to create a portable
portlet specification but only an optimized implementation specific API :)
>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 agree that, for performance reason, there should be a way for portlet
writer to
state that their portlet does not require post-processing, provided the portal
implementation allows it.
> >
> >- 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:
Gee, Thomas, I was just trying to describe the issues, not giving my opinion.
Now, I *have* to restate my POV on this issue. ;)
>* 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.
I would agree to this only if you can show me workable fragment guidelines
for non nestable markups like WML or SMIL. (I don't know VoiceXML but I
gather it's also non nestable).
What I mean by "non nestable" is that the markup does not provide a general
element that can be recursively included and that naturally define a segment
of the aggregation space (HTML has <table>, XSL:FO has <block>, etc...).
For me your current proposition is a workable standard (but inelegant) for
defining
portlets that output content in a nestable content but can't be used as a
standard
for non-nestable markup.
> >
> > >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
> > V
>
>
>
>--
>--------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Search: <http://www.mail-archive.com/[email protected]/>
>List Help?: [EMAIL PROTECTED]
--
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]
