At 16:54 14/02/2001 +0100, you wrote:
>Hi,
>
>I'm meanwhile convinced, that this discussion won't lead to a consensus,
>if each of us keeps defending his view on a technical level. However, I
>really like to find a compromise that everybody can agree on. On a meta
>level of this discussion, I can see the point that it would hurt the "SAX
>advocates" more, if there is no way of producing direct SAX output, than
>it'd be the other way round. That's why we where trying to find a way of
>integrating the SAX requirements, without integrating the additional
>methods. I think we have found a good way that might be acceptable for all
>of us. :-)
I don't think the issue is at all technical, purely on defining the scope
and goal of the API.
>The basic idea is that the Portlet API defines the interfaces and default
>implementations of abstract portlet classes (that are subclassed by the
>actual portlets). A certain portlet container implementation could replace
>these default implementations and make use of extensions that are specific
>to this portlet container implementation:
I've read other the proposal and there are some details missing for getting
the full picture
(like what would be the methods provided in the PortletResponse API ?).
I don't have the time right now for proposing my own compromise but I'll
write one that will allow
both direct doc fragment byte streaming and high level valid documents SAX
event streaming so that
we can continue the discussions with 2 concrete propositions.
--
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]
