David H. DeWolf wrote:
Ralph Goers wrote:
So the real question is, are we here to just implement the RI for the
spec or can we go beyond it and if so, how?
From a historical perspective, the general thought of the pmc has been
that pluto should be scoped at the portlet container level while other
portals projects should focus on the portal services. Whether or not
the container needs to only focus on the reference implementation of
go beyond is what's up for discussion.
I understood that. That is why I posed the question. I guess I'm of the
opinion that I'd like to see Pluto go beyond it. If not in the Pluto
"core" then through some kind of extension.
As for my self, I believe:
1) Pluto should focus on the following 3 goals (in order and as stated
in it's mission):
- reference implementation
- easy portlet testing/development
- embeddable container for portal/webapp developers
2) Jetspeed should be the focus of enterprise portal development
3) Other subprojects of the protals community should provide
additional functionality/features.
In other words, yes, we can *and should* go beyond the specification.
That said, we need to determine the appropriate place.
That is the problem. Doing it in Jetspeed is of little value to me. What
I would like to find a way to do is to extend the portlet spec so that
various portals all implement these extensions. Since quite a few
portals use pluto, adding these extensions there is a good way to
accomplish this. That said, how portlets are hot deployed is not
necessarily something I believe should be added to a portlet spec (but
I'm open to the idea if someone thinks it should be).
The question at hand (auto-deployment in pluto) is borderline
functionality to me. It specifically hits the second goal of pluto
(easy portlet testing/development), but could also be seen as
enterprise functionality.
I seem to recall having a discussion at ApacheCon in San Diego regarding
a "Portal Commons". Perhaps this, as well as some of the things I have
proposed, really belong there. Then both Jetspeed and Pluto could get
them there. If I recall the discussion correctly though, some of us
Cocoon folks were looking for ways to borrow Jetspeed functionality
without having to pick apart Jetspeed to do it. In fact, I believe the
specific component we were looking for was Jetspeed's hot deployer. At
the time Cocoon didn't have such a thing. I believe shortly afterwards
Carsten went and implemented it for Cocoon so the issue disappeared. To
be honest, I can't really recall why Portal Commons never came to be.
I've been following the Pluto lists for some time although I don't
really participate, and I've seen this discussion come up at various
times. There always seems to be a little tension over how robust the
container should be. Frankly, I see no reason why the proposed
functionality shouldn't be there if it isn't something that could be
leveraged outside of Pluto. At the same time I wouldn't like to see
Pluto tied to Tomcat if this requires it.
Ralph
