You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Santiago Gala <sg...@hisitech.com> on 2001/12/11 14:22:13 UTC
New API specification
Setera, Craig wrote:
>I took a look at the new portal API specification. It looks excellent. I
>like the parallels being drawn between the portlet API and the servlets API.
>When is the plan to decide on this proposal and begin implementation? Soon
>after 1.3a2?
>
The idea after we have stabilized 1.3a2, we could proceed in two
separate lines:
- Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
security, ...
- Go for a 2.0 that would use the new portal API specification. For
this work I would like to have feedback from the IBM team involved in
Websphere portal server, since they were the original authors (after
list discussion and feedback) of the proposal.
The better features in the new Portlet API proposal:
- Pure XML portal framework becomes possible, with end-to-end SAX event
streams, instead of memory objects or character streams
- Better parameter isolation between portlets
- More independent from base frameworks
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Frans Thamura <ft...@yahoo.com>.
Great track...; this project is getting exciting...
+1.
Frans
----- Original Message -----
From: "Paul Spencer" <pa...@apache.org>
To: "Jetspeed Developers List" <je...@jakarta.apache.org>
Sent: Wednesday, December 26, 2001 10:28 PM
Subject: Re: New API specification
> +1 on "I would like to start a new cvs for Jetspeed-2"
>
> As to the framework choices, I do not know enough to form an opinion.
>
> Paul Spencer
>
> David Sean Taylor wrote:
>
> >>The idea after we have stabilized 1.3a2, we could proceed in two
> >>separate lines:
> >> - Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
> >>security, ...
> >> - Go for a 2.0 that would use the new portal API specification. For
> >>this work I would like to have feedback from the IBM team involved in
> >>Websphere portal server, since they were the original authors (after
> >>list discussion and feedback) of the proposal.
> >>
> >
> > We can do both. I am more interested in 2.0...
> >
> > I would like to start a new cvs for Jetspeed-2, similar to how Turbine
now
> > has Turbine-2 and Turbine-3 repos. Jetspeed-2 would be based on the
Portlet
> > API, and a Portlet Container SPI.
> >
> >>From reading the postings on the emails, and from personal experiences,
> > there is some question as to whether we should continue to base Jetspeed
on
> > the Turbine framework.
> > I see some basic framework choices available at jakarta:
> >
> > * Avalon?
> > * Cocoon-2
> > * Struts
> > * Turbine-2
> > * Turbine-3
> > * none
> >
> > IMO, we are not leveraging jakarta-commons, and we should be.
> > When looking to refactor the jetspeed architecture, we should have a
good
> > knowledge of all the apache projects and their capabilities. I will be
> > spending the next few weeks doing exactly that.
> >
> > David
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Chris Kimpton <ki...@yahoo.com>.
Hi,
> +1 on "I would like to start a new cvs for Jetspeed-2"
>
Is Jetspeed-2 a major (>60%) rewrite? If so, then I think it should
be a new CVS module. But if there is going to be a lot of common
code, that will need to be maintained in both - then it seems better
to keep it one place.
> As to the framework choices, I do not know enough to form an
> opinion.
>
Same here ;-)
Chris
=====
Need somewhere to Live in London? - Then go to http://freeflats.com
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Paul Spencer <pa...@apache.org>.
+1 on "I would like to start a new cvs for Jetspeed-2"
As to the framework choices, I do not know enough to form an opinion.
Paul Spencer
David Sean Taylor wrote:
>>The idea after we have stabilized 1.3a2, we could proceed in two
>>separate lines:
>> - Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
>>security, ...
>> - Go for a 2.0 that would use the new portal API specification. For
>>this work I would like to have feedback from the IBM team involved in
>>Websphere portal server, since they were the original authors (after
>>list discussion and feedback) of the proposal.
>>
>
> We can do both. I am more interested in 2.0...
>
> I would like to start a new cvs for Jetspeed-2, similar to how Turbine now
> has Turbine-2 and Turbine-3 repos. Jetspeed-2 would be based on the Portlet
> API, and a Portlet Container SPI.
>
>>>From reading the postings on the emails, and from personal experiences,
> there is some question as to whether we should continue to base Jetspeed on
> the Turbine framework.
> I see some basic framework choices available at jakarta:
>
> * Avalon?
> * Cocoon-2
> * Struts
> * Turbine-2
> * Turbine-3
> * none
>
> IMO, we are not leveraging jakarta-commons, and we should be.
> When looking to refactor the jetspeed architecture, we should have a good
> knowledge of all the apache projects and their capabilities. I will be
> spending the next few weeks doing exactly that.
>
> David
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by David Sean Taylor <da...@bluesunrise.com>.
> The idea after we have stabilized 1.3a2, we could proceed in two
> separate lines:
> - Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
> security, ...
> - Go for a 2.0 that would use the new portal API specification. For
> this work I would like to have feedback from the IBM team involved in
> Websphere portal server, since they were the original authors (after
> list discussion and feedback) of the proposal.
We can do both. I am more interested in 2.0...
I would like to start a new cvs for Jetspeed-2, similar to how Turbine now
has Turbine-2 and Turbine-3 repos. Jetspeed-2 would be based on the Portlet
API, and a Portlet Container SPI.
>From reading the postings on the emails, and from personal experiences,
there is some question as to whether we should continue to base Jetspeed on
the Turbine framework.
I see some basic framework choices available at jakarta:
* Avalon?
* Cocoon-2
* Struts
* Turbine-2
* Turbine-3
* none
IMO, we are not leveraging jakarta-commons, and we should be.
When looking to refactor the jetspeed architecture, we should have a good
knowledge of all the apache projects and their capabilities. I will be
spending the next few weeks doing exactly that.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Santiago Gala <sg...@hisitech.com>.
Jason van Zyl wrote:
>On 12/11/01 10:43 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
>
>>Jason van Zyl wrote:
>>
>>>On 12/11/01 8:58 AM, "Paul Spencer" <pa...@apache.org> wrote:
>>>
>>>>I agree with the general idea of completing 1.3 and starting a 2.0 based
>>>>on a new API.
>>>>
>>>Possibly based on Turbine 3.x? :-)
>>>
>>I agree, provided that a stable turbine release is scheduled. We have
>>had to deal with a lot of problems because of APIs moving around.
>>
>
>What problems have you had since the release of 2.1? I think that a lot of
>your problems are self inflicted.
>
Lately things are rather smooth :-) But I don't want to do a premature
migration and open the can of worms again...
>
>>We
>>have chosen to follow a more stable path as the code base grows, and as
>>people starts using it for production systems we need a clean evolution
>>path.
>>
>>BTW, I was discussing with a colleague here and he said that he found
>>disgusting the mixture in Turbine API between two separate issues in the
>>same service:
>>
>>- Authentication
>>- User Management (The User data)
>>
>>After a little thought and talk, we agreed. In a lot of cases,
>>authentication can be handled by quite separate mechanisms, for instance
>>a corporate LDAP or JAAS. While in some projects we *must* use these
>>resources, we *cannot* have write access to the corporate repositories,
>>thus we need to store User Info in separate places from the one provided
>>by the default TurbineSecurity. Which implies we need to fiddle with
>>Turbine architecture.
>>
>
>Than you have to look at the proposals for turbine 3 and speak up now. What
>you speak of makes sense so make sure you talk about it on the Turbine list.
>If you don't participate in the development of turbine 3 (it's still really
>in its infancy so you haven't missed anything) and there are things that you
>need that don't appear than don't blame the turbine developers.
>
I'll try. I'm overwhelmed, but I will try to look for threads and
comment on them.
>
>
>>Do you know how is it evolving in Turbine 3.0? Are there generic
>>Persistence Services, that we could use for both PSML and User Data?
>>
>
>Huh? Do you mean can you store user information in the database and in XML,
>or in flat files?
>
>
A generic persistence service, that could be used to store both XML
documents and java objects (maybe through a mapping like torque, castor,
...) but which could be configured to store the objects either:
- in flat files
- in databases
- in LDAP directories
- ...
and that is uncoupled from the security service (except maybe through an
Id for retrieving the info).
Currently, if you migrate the user service to LDAP, the user info will
not be written (save is not implemented in the service).
Maybe this already exisst, but I'm not aware of it (excuse my ignorance).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by David Sean Taylor <da...@bluesunrise.com>.
>
> What problems have you had since the release of 2.1? I think that a lot of
> your problems are self inflicted.
>
Yes, by choosing to base Jetspeed on Turbine ;-)
I personally had lots of problems getting all the jars to sync up between
torque/turbine/velocity. I don't want to go there again,.
So what has changed in Turbine-3?
Is it still based on ECS?
Are there still modules (screens/actions/layouts ...)?
Where can we find out about the architectural changes?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/11/01 10:43 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
> Jason van Zyl wrote:
>
>> On 12/11/01 8:58 AM, "Paul Spencer" <pa...@apache.org> wrote:
>>
>>> I agree with the general idea of completing 1.3 and starting a 2.0 based
>>> on a new API.
>>>
>>
>> Possibly based on Turbine 3.x? :-)
>>
> I agree, provided that a stable turbine release is scheduled. We have
> had to deal with a lot of problems because of APIs moving around.
What problems have you had since the release of 2.1? I think that a lot of
your problems are self inflicted.
> We
> have chosen to follow a more stable path as the code base grows, and as
> people starts using it for production systems we need a clean evolution
> path.
>
> BTW, I was discussing with a colleague here and he said that he found
> disgusting the mixture in Turbine API between two separate issues in the
> same service:
>
> - Authentication
> - User Management (The User data)
>
> After a little thought and talk, we agreed. In a lot of cases,
> authentication can be handled by quite separate mechanisms, for instance
> a corporate LDAP or JAAS. While in some projects we *must* use these
> resources, we *cannot* have write access to the corporate repositories,
> thus we need to store User Info in separate places from the one provided
> by the default TurbineSecurity. Which implies we need to fiddle with
> Turbine architecture.
Than you have to look at the proposals for turbine 3 and speak up now. What
you speak of makes sense so make sure you talk about it on the Turbine list.
If you don't participate in the development of turbine 3 (it's still really
in its infancy so you haven't missed anything) and there are things that you
need that don't appear than don't blame the turbine developers.
> Do you know how is it evolving in Turbine 3.0? Are there generic
> Persistence Services, that we could use for both PSML and User Data?
Huh? Do you mean can you store user information in the database and in XML,
or in flat files?
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Santiago Gala <sg...@hisitech.com>.
Jason van Zyl wrote:
>On 12/11/01 8:58 AM, "Paul Spencer" <pa...@apache.org> wrote:
>
>>I agree with the general idea of completing 1.3 and starting a 2.0 based
>>on a new API.
>>
>
>Possibly based on Turbine 3.x? :-)
>
I agree, provided that a stable turbine release is scheduled. We have
had to deal with a lot of problems because of APIs moving around. We
have chosen to follow a more stable path as the code base grows, and as
people starts using it for production systems we need a clean evolution
path.
BTW, I was discussing with a colleague here and he said that he found
disgusting the mixture in Turbine API between two separate issues in the
same service:
- Authentication
- User Management (The User data)
After a little thought and talk, we agreed. In a lot of cases,
authentication can be handled by quite separate mechanisms, for instance
a corporate LDAP or JAAS. While in some projects we *must* use these
resources, we *cannot* have write access to the corporate repositories,
thus we need to store User Info in separate places from the one provided
by the default TurbineSecurity. Which implies we need to fiddle with
Turbine architecture.
Do you know how is it evolving in Turbine 3.0? Are there generic
Persistence Services, that we could use for both PSML and User Data?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/11/01 8:58 AM, "Paul Spencer" <pa...@apache.org> wrote:
> I agree with the general idea of completing 1.3 and starting a 2.0 based
> on a new API.
Possibly based on Turbine 3.x? :-)
> Paul Spencer
>
> Santiago Gala wrote:
>
>> Setera, Craig wrote:
>>
>>> I took a look at the new portal API specification. It looks
>>> excellent. I
>>> like the parallels being drawn between the portlet API and the
>>> servlets API.
>>> When is the plan to decide on this proposal and begin implementation?
>>> Soon
>>> after 1.3a2?
>>>
>> The idea after we have stabilized 1.3a2, we could proceed in two
>> separate lines:
>> - Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
>> security, ...
>> - Go for a 2.0 that would use the new portal API specification. For this
>> work I would like to have feedback from the IBM team involved in
>> Websphere portal server, since they were the original authors (after
>> list discussion and feedback) of the proposal.
>>
>> The better features in the new Portlet API proposal:
>> - Pure XML portal framework becomes possible, with end-to-end SAX event
>> streams, instead of memory objects or character streams
>> - Better parameter isolation between portlets
>> - More independent from base frameworks
>>
>>
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New API specification
Posted by Paul Spencer <pa...@apache.org>.
I agree with the general idea of completing 1.3 and starting a 2.0 based
on a new API.
Paul Spencer
Santiago Gala wrote:
> Setera, Craig wrote:
>
>> I took a look at the new portal API specification. It looks
>> excellent. I
>> like the parallels being drawn between the portlet API and the
>> servlets API.
>> When is the plan to decide on this proposal and begin implementation?
>> Soon
>> after 1.3a2?
>>
> The idea after we have stabilized 1.3a2, we could proceed in two
> separate lines:
> - Go for a 1.3 that is basically as 1.3a2 with bugs removed, better
> security, ...
> - Go for a 2.0 that would use the new portal API specification. For this
> work I would like to have feedback from the IBM team involved in
> Websphere portal server, since they were the original authors (after
> list discussion and feedback) of the proposal.
>
> The better features in the new Portlet API proposal:
> - Pure XML portal framework becomes possible, with end-to-end SAX event
> streams, instead of memory objects or character streams
> - Better parameter isolation between portlets
> - More independent from base frameworks
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>