Santiago Gala wrote:
ingo schuster wrote:
At 20:04 02/16/01, Raphal Luta wrote:
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.
Steve,
Suggestion: Add a configuration tag to the portlet definition
which specifies whether or not the portlet will produce partial
or full content.
You probably mean the deployment descriptor, not the portlet definition...
Suggestion: Create portlet wrappers for full content stripping
Steve,
Can you give an example of how such a stub should look like? You may indeed
have good ideas here...
Cheers,
Thomas B.
- Original Message -
From: "Steve Freeman" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Sunday, February 18, 2001 21:32
Subject
At 20:04 02/16/01, Raphal Luta wrote:
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.
Both times are ok with me. Did we already fix the day (Mo or
ingo schuster wrote:
At 20:04 02/16/01, Raphal Luta wrote:
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.
Both times are ok with me.
Thomas,
Excuse me for not being fully up to snuff...
At 10:25 AM 2/19/2001 +0100, you wrote:
Steve,
Suggestion: Add a configuration tag to the portlet definition
which specifies whether or not the portlet will produce partial
or full content.
You probably mean the deployment
,
Can you give an example of how such a stub should look like? You may indeed
have good ideas here...
Cheers,
Thomas B.
- Original Message -
From: "Steve Freeman" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Sunday, February 18, 2001 21:32
Subject: Re: [vote] P
Santiago Gala wrote:
- we can first aggregate content, and then the container will
lay it out and style it. (This is my view)
This is an interesting thought, but how would the container know
how to "style" content provided by a particular portlet ?
There are simple special cases like
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 :)
Thomas Schaeck wrote:
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
At 20:04 02/16/01, Raphal Luta wrote:
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
Sam Ruby wrote:
Thomas Schaeck wrote:
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
At 07:36 PM 2/18/2001 +0100, you wrote:
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
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
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
I'd like to applaud Ingo for stepping up and trying to find a middle ground.
Impressive ascii-diagram too :)
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's
ResponseImpl
can provide additional methods such as
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
[EMAIL PROTECTED] wrote:
Santiago Gala wrote:
Do you mean that javax.servlet.* is more standard than javax.xml.* (Trax
and Jaxp)?
What I am trying to point out is that it is not good for a standard Java
API depend on other Java APIs that are not part of the JDK classes.
If you
At 08:11 02/15/01, David Sean Taylor wrote:
I'd like to applaud Ingo for stepping up and trying to find a middle ground.
Impressive ascii-diagram too :)
SaxPortlet has specific knowledge about the portlet container's
implementation of the response. Now the portlet container's
ResponseImpl
Raphal Luta wrote:
(...)
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
Not really. If you want to process sax events in the portal
engine, then it
doesn't make sense to convert it into a stream in the SaxPortlet and
reparse it on the other side of the portlet in order to convert it back
into sax events.
I wasn't suggesting that!
Guess I misunderstood the
[EMAIL PROTECTED] 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.
Point 1: Should JetSpeed require portlets to produce full documents ?
Producing full documents
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
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
:45 AM
Please respond to "JetSpeed" [EMAIL PROTECTED]
To: JetSpeed [EMAIL PROTECTED]
cc:
Subject: Re: [vote] Portlet API
[EMAIL PROTECTED] 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
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
At 22:24 12/02/2001 +0100, you wrote:
Raphal Luta wrote:
snip templating system description
Point 1:
Should the Portlet API mandate that portlet only output full documents rather
than document fragments ?
You mean here "proper" markup? This is more radical thant point 2. And
impossible to
At 22:35 12/02/2001 -0800, you wrote:
Ive been reading this thread with interest. I have some comments, questions
and suggestions:
Point #1 - Portlet API mandate that portlets only output full documents
rather than document fragments:
- There is some confusion WRT portlets producing document
don't implement, I am not going to run". Portlet portability adios!
Cheers,
Thomas
- Original Message -
From: "David Sean Taylor" [EMAIL PROTECTED]
To: "JetSpeed" [EMAIL PROTECTED]
Sent: Tuesday, February 13, 2001 7:35
Subject: RE: [vote] Portlet API
Ive been readin
At 18:44 12/02/2001 +0100, you wrote:
At 14:12 02/12/01, Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted upon.
For those who did not follow the arguments, pleae read the "Secure
At 22:04 12/02/2001 +0100, you wrote:
Raphael,
I think we should not decide on these two points as isolated items, they
need to be put into perspective to make sure that everybody fully
understands the consequences and implications before voting. The larger
question behind this is whether we
because through the SAX
mechanism complete output would be injected into the otherwise correct page.
Now I will shut up and not comment on this particular topic anymore.
Cheers,
Thomas B.
- Original Message -
From: "Santiago Gala" [EMAIL PROTECTED]
To: "JetSpeed"
Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted
upon.
For those who did not follow the arguments, pleae read the "Secure
Portlets"
thread in the mail archive before
Raphael,
Please let us clearify your questions a bit more (see my comments below).
At 14:12 02/12/01, Raphal Luta wrote:
Following the discussions on the Portlet API, there's no strong consensus
on the following points of the Portlet API and so they should be voted upon.
For those who did not
Raphael,
I think we should not decide on these two points as isolated items, they
need to be put into perspective to make sure that everybody fully
understands the consequences and implications before voting. The larger
question behind this is whether we want JetSpeed to be a
Ive been reading this thread with interest. I have some comments, questions
and suggestions:
Point #1 - Portlet API mandate that portlets only output full documents
rather than document fragments:
- There is some confusion WRT portlets producing document fragments vs full
documents.
AFAIK,
36 matches
Mail list logo
