David Sean Taylor wrote:
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.
Sounds good to me.
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.
There are some that I think may be interested that participate on the
pluto dev list (we've had a recent flux of activity from new members),
but I'll go ahead and let them speak for themselves.
It goes without saying that if I'm the only one that has these
requirements, it may be silly to open source this. That said, it seems
to me that this is also the minimum required for development and
testing, so there may be uses outside of what I'm using this type of
solution for.
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 ....
Sure, basically, the aggregation server needs to know which portlets are
available to it's disposal. In my mind, the portlet registry is
provided to store this information. Administration tools may be
available to manipulate this info.
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?
Excuse my ignorance here. . .
From what I've seen in jetspeed over the past week or so, PSML is a
markup language which defines how pages are layed out. Is this correct?
If so, then know, I'd prefer not. My idea of a page is much simpler,
it's basically a grouping of portlets which are aggregated together. It
contains no layout information whatsoever.
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?
No, I do not envision the ui being able to be adjusted. The only
modification to pages would be the portlets which are actually grouped
together on a page. In other words, a grouping of portlets could be
modified, but how they are layed out and their look and feel would not be.
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?
Great question. When I say "single war", I'm referring to the
aggregation server - not necessarily the portlets. My instinct says
that to meet this requirement a cross context dispatch must be used and
portlets must be deployed to the app server seperately (which is
acceptable). If anyone has a better idea - I'd LOVE to hear it.
Will it require a database? I have found that databases can complicate
things and quickly add layers of fluff.
Ya, I'm struggling with this question myself. Currently what we have
done in pluto does use a database to allow for the portlet registry and
page registry (groupings) to be dynamic. That said, I go back and forth
almost every day wondering how much I like this. The other solution
I've kicked around is to serialize xml for these. . .again, this is an
area I'd love to discuss with others and make a community descision.
Will it support Derby, or all flavors of databases?
If we support derby, I'd assume we'd support any jdbc connection through
a datasource simply b/c it's simple to do. But, by no means is that I
requirements that I have.
Will you use the DAO classes from Pluto, or will you use an existing DAO
or ORM solution?
I like the pure dao's b/c they don't add unecessary dependencies,
however, I don't like the bloat that comes with sql. I've considered
iBatis, am not a huge fan of OJB and we can't use hibernate. I'm open
to whatever others think. Again, collaboration will help us find the
best solution -- and perhaps this isn't even a discussion point if we do
away with the db all together.
Will users and credentials be stored? If yes, in a database, XML?
No, In my perfect world it would rely 100% on the app servers security
mechanisms.
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?
Well, for both applications that I'm using this solution for, this isn't
really a portal. It more of a webapp which I must be able to easily
plug in components to - many of which come from external sources and I
don't develop. The solution is similar to what Geronimo is doing (hence
my interest), and what Felix has mentioned wanting to do.
For one of the solutions, this is for an admin console which is embedded
in a device. Think of a generic linksys router and the web console that
comes with it and then imagine that more than one entity is providing
different aspects of the management console. B/C it's embeded,
resources are limited and we'd like to keep it as small as possible.
Because of these use cases, this isn't a traditional portal so I don't
see "users" wanting more. That said, that is always a temptation, but
one that we've purposely decided to shun.
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?
I think that's a very fair question. I have no problem if the answer is
no. *If* we can maintain scope and keep this solution light weight, I
do believe that a second "light weight" portal may help jetspeed. The
reason is that it *may* attract more users to the portal world (perhaps
because it lowers the cost of entry - and no, that's not being critical
of jetspeed, just something we should think about and evaluate). Once
this attraction occurs and users begin to ask for more, we simply say -
hey - look at jetspeed and hopefully provide them an upgrade path.
At the same time, *If* we allow this light solution to grow outside of
the original scope, there is no doubt that it will detract from
jetspeed. If we as a community believe that my use cases and
requirements are unique enough that they don't warrent a solution within
apache portals, I take no offense.
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.
Fair enough. We at Pluto know all about lack of committers :)
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?
On one hand, I'm not sure how this affects the current make up of
portals at all. If the jetspeed team has no interest, either nothing
changes or the pluto portal driver moves outside of pluto and jetspeed
still isn't affected since none of the active pluto developers are
active in jetspeed anyways.
On the other hand, I'd very much like to see this be the bridge between
the two projects. *If* we can find a way for the two teams to
collaborate I would absolutely love it. I'm very willing to dump the
pluto portal driver and use jetspeed components instead (though I do
have a strong preference to the pluto 1.1 container). If that approach
was chosen, I would think it would be natural for jetspeed to be an
extension of "the aggregation server". That said, I definately
understand how that comment may ruffle some feathers - especially
considering that I have similar feelings regarding "dumping" pluto and
am only putting that on the table since I know it may be best for the
community.
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.
Perhaps any responses to these comments should go in another thread so
that we don't get off track. . .
I can't say I don't like jetspeed. From what I can tell, it simply does
not meet my requirements. That said, there are two things that are not
ideal IMHO (and perhaps my understanding is wrong and these really
aren't issues):
I don't really like is the repo layout and build -- I don't think that
they lend themselves to easily discovering the core components of
jetspeed. I found I had to research and look around quite a bit to feel
like I had any clue what lived where.
The other thing I don't like is the setup required. I'd like to be able
to take a jetspeed war, deploy it, and go. . .I don't want to have to
create db schemas, build for specific app servers, etc. . .before
running. IMHO, either an installer should do that work for me, jetspeed
should initialize itself at startup, or the default build should not
require this prep work.
Beside those minor things, I really have no problem with jetspeed.
Finally, are you willing to base your portal on the Jetspeed API?
Yes, as long as it doesn't have a whole ton of dependencies, a lot of
service interfaces that the core is dependent upon but I don't need, and
the concept of pages and page layouts (PSML) are seperated from each other.
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.
Thanks. That's much appreciated and I know you mean it.
I don't want to see the community splintered.
I agree. Quite frankly, I allready feel like a lone ranger over at
pluto and whether you believe it or not, my original proposal was meant
to be a community building effort - NOT a splintering one :)
I really don't want to see two completely different Java portal
technologies at Apache Portals. I think that is the wrong message.
I understand. Perhaps my problem is that I'm not really looking for a
portal - I'm looking for an aggregation server which utilizes the
portlet spec for it's disperate content.
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.
Hopefully I explained why *I don't think* jetspeed meets my requirements
above. This REALLY IS about a light weight portal to me. If you think
my requirements are so unique that it doesn't warrent the attention it's
getting. . .just say so and we can drop it.
