Im going to make an effort to try again to respond.
Im willing to forgive and forget what was said on the ill-fated last thread.
Please, (me included) this time lets try to stay on a topic and try not
to get personal.
David H. DeWolf wrote:
I, (in the past and now as well) have a need for a "light weight" portal
Are there others in your community? I believe there are now two people
in your community that I am aware of, yourself and Raphael Luta. Others
please speak up.
solution. This light weight portal solution is basically an
"aggregation server". I consider it more like a simple wrapper around
the portlet container. It provides the following:
1) Ability to invoke portlets and include their content into a webapp in
a compliant manner.
2) Ability to manage a "portlet registry" at runtime.
Could you elaborate more ....
3) Ability to define a "page" or grouping of portlets at runtime but
have no layout associated with it.
Will you be using PSML or another technology?
4) Ability to customize rendering using different technologies (simple
jsp, a servlet, velocity, etc. . .) without having to jump through
hoops. Custom tags to insert rendering such as the <pluto:render> tag
would be nice.
Does this include a UI customizer component, or a simple, JSP editor as
the customizer?
5) Ability to have a portable solution which can be packaged as a single
war (not built differently for different environments) and deployed on
any compliant servlet container.
If its a single war file, then how will standard portlet applications be
deployed to a single war file solution? Will all portlet applications
run inside the same class loader, same session space as the portal? What
about resource collisions?
Will it require a database? I have found that databases can complicate
things and quickly add layers of fluff.
Will it support Derby, or all flavors of databases?
Will you use the DAO classes from Pluto, or will you use an existing DAO
or ORM solution?
Will users and credentials be stored? If yes, in a database, XML?
There may be one or two additional requirements that I'm not thinking of
right now, but literally, this is a very simple portal solution and
needs to be void of additional "fluff". The solution does not need to
include any other "value added" services - and it would be a pretty big
negative if it did.
How do you intend to keep the solution light weight?
That seems like a double-edged sword. Your user base will ask for more
features, but you will be locked to a light-weight philosophy. Will your
charter build in the ability to "grow" to a medium-weight or
heavy-weight portal?
I keep repeating myself here, I think a light-weight portal is
questionable as its the natural progression of the portal space to
integrate with technologies and "grow". The end result will be two
portal solutions for Apache Portals. Maybe we should ask ourselves the
question first before going on:
Do we want to have more than one portal solution at Apache Portals?
Frankly, we don't even have enough committers for any of our projects
right now. That is a concern to me, even without the additional
maintenance of 4th portal solution here.
I have been developing this solution in Pluto, however, at apachecon, I
got wind of the fact that some people may not be comfortable with this
and would prefer that the test driver does not include things such as #2
and #3 above (and perhaps others). The solution needs to be of
production strength.
Would others please provide their ideas on where the best place for this
solution is, whether it may be provided in a solution we allready have
(besides the pluto portal in question), and how we should move forward?
I will be proposing a Jetspeed Lite Edition on this email list as a
solution using Jetspeed technologies to assemble a light weight portal.
I believe that would be a more "synergized" and community building,
rather than community splintering approach. Now this implies that your
solution is community-splintering. And frankly, that is not fair at all,
to simply imply it. So please, tell us how Jetspeed Components and the
Jetspeed team of developers and contributors fit in with this solution,
and how we won't feel that we are being ignored and stepped over and
splintered?
Also, if you don't like the Jetspeed solution, just say so.
Gawd knows we are not perfect. There are problems.
Just speak your mind and tell us why its just unusable for a lightweight
portal solution.
Finally, are you willing to base your portal on the Jetspeed API?
I welcome your enthusiasm, and as I told you at ApacheCon, for what its
worth, I fully support your efforts to develop portal technology here at
Apache Portals. I just want to make sure that the portals community
stands behind your proposal, and that we don't dismiss existing solutions.
I don't want to see the community splintered.
I really don't want to see two completely different Java portal
technologies at Apache Portals. I think that is the wrong message.
However, if there are those here in the community who feel that Jetspeed
is the wrong technology, then just stop beating around the bush and say
so. Because in the long run, I don't think this is really about a
light-weight portal. I just cannot see (see my comments above) how a
portal can stay light-weight and maintain the requirements and needs of
a valid user base and community.
