At 14:33 16/02/2001 +0100, you wrote:
>I haven't had much feedback on the proposed compromise but after a private
>discussion with Raphal I think that some more detailed description will be
>helpful. Furthermore, even though my proposal allowed to use both
>approaches (portlets delivering output streams to the container as well as
>portlets delivering sax events to the container) it still stressed in some
>way, that the stream based approach would be the basic, standard way,
>whereas the sax event way was only an extension. (And meanwhile, since I
>didn't finish this mail yesterday, Raphael send an proposal that exactly
>inverts this emphasis :) )
That was its goal ;)
><snip proposal description>
>The main disadvantages:
>* The base PortletResponse interface is "naked". A PortletResponse object
>doesn't help anything, you always have to cast it. I.e. that there is no
>"default way" that the portlet API gurantees to work always and in every
>container.
>
>* There can be portlet containers that support only some portlet types.
>Portlets do not necessarily run on _every_ portlet container, but only on
>those that support their type. (This is compareable to the beginning of
>EJBs when not all containers supported entity beans for example).
>* A developer can't write a portlet that implements the portlet interface
>and extends some other class at the same time. As there is no
>multi-inheritence in java, portlets are forced to extend only the abstract
>portlet classes.
That's a pretty big characteristic as it basically means the API naturally
segments the "portlet space" in
disjonctive sets, in particular a portlet can't easily mix its output mode
depending on the markup
generated (but then this is a compromise...).
Actually, I was thinking about the possible use of an implementation of
the base portlet API (which would
be supported by any container) and it actually may be useful for building
action-like portlet which never
output directly any data but do some processing, maybe update the portlet
context and then redirect
to another portlet for generating output. Maybe this is worth considering
if we chose this compromise
path...
Another note on the proposed API is that I think my proposed solution for
handling content models
(through the descriptors) is way better than using different sub-interfaces
per content model because
it will lead to an explosion of sub-interfaces (for example how do you
define an interface for a SAX
based portlet which wants to output XHTML fragments but full WML ?
SaxWithXHTMLFragmentButFullDocumentInOtherMarkupsPortlet ;-P )
>I updated the java docs in the proposals directory so that everybody can
>have a look at them. They are more detailed, but I hope that this mail did
>also make the idea clear.
>I still owe you a proposal that defines which rules document fragments
>will have to comply to in order to by a "well-defined fragments". Didn't
>get to it yet, but it'll follow.
>
I'm mostly interested in the WML fragments you'd like to propose because
it's a really tough
issue...
>I hope that the above is a fair compromise in which all of us should find
>their requirements and design goals taken into account. However, for none
>of us it will be as neat as we whished it'd be - but that's the nature of
>compromises...
>
>Ok, then: comments?
I think the proposed API in definitely fair but if we can't find a
reasonable use for the empty
PortletResponse looks a bit strange.
I alos think we should treat all the implementations in the same way so
either define only
SaxPortlet and StreamPortlet and leave the content model in the descriptor
(my preferred
approach) or have a SaxFragment/SaxFull/StreamFragment/StreamFull
implementations.
>ingo.
>
>P.S.: Raphael suggested to have an IRC chat on Monday or Tuesday evening
>(european time). That'll give us the possibility to speed up the
>discussion and bring it to an end. I think this is a good idea.
Yes, I still think this woud be a good idea in order to settle this
question definitely and move forward...
Based on the last 2 compromise proposals, I think the decisions we need to
make now are:
Q1. Do we want an API that offer a stream/content model (s/cm) for portlets
that "guarantee"
portability at the cost of ease of portal implementation ?
Yes -> my SAX based proposal -> END
No -> Depending on the s/cm, some portlets will not run on some portals
Q2. Do we want a symmetric API between SAX and Stream and the cost defining
an unnatural
base PortletResponse interface ?
Yes -> Ingo's latest proposal
No -> Byte streams must be chosen as the stream -> either Ingo's
previous proposal or
my "reversed" SAX proposal (they are the same anyway)
Q3. Do we want to bind the API with some cm ?
Yes -> Ingo's content model sub-interfaces
No -> Use deployment time/runtime time content model descriptors
Q4. Which content models do we want to define and which do we want to make
mandatory ? (Easy for some markups, very tricky for others...)
What is the default cm for unspecified markups ?
I think that once these 4 questions are decided, the rest is API refining
(the User model for example...).
What would be the ideal time for an IRC chat ?
Personnally I'd prefer either between 12:00 and 130:00 GMT (but I guess it's
a bit early for the PST people out there) or near 19:00 - 20:00 GMT.
--
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/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
