On 12/17/05, David Sean Taylor <[EMAIL PROTECTED]> wrote: > Raphaël Luta wrote: > > > > I'm not familiar enough with the current feature level of Pluto portal > > driver > > to have a definite idea but the best technical foundation. > > I know Jetspeed spreing based architecture and pipeline processing is > > supposed > > to allow us to scale it down easily, but until somebody actually tries it's > > more a theoretical possibility than a reality. > > > That is exactly what we are proposing to do. > We believe it is possible. Give us a chance to prove it first before > diving into something completely new, which might end up conflicting > with and competing with the existing Jetspeed project and community.
I find this statement a little misleading. No one is suggesting we start something completely new. In fact, what I've continually said is that we need to take a look at what allready exists (between jetspeed, cocoon, and pluto) and refactor it into a basic portal which is distributed and developed seperately. > > We have a 2.01 release to put out next week. We will then start work on > a lightweight assembly of Jetspeed-2. Additionally, we will start > writing light-weight implementations of most of the database components. > > We are a small team at Apache Portals. It is essential that we all work > together towards the same vision. This is what Apache is all about. +100 - but we need to find the same vision. It's fairly apparent that we're not on the same page yet. I think the first step is diving into the work that has been done in each project and begining to analyze what we have. I have begun to look into jetspeed in more depth (and hopefully will have time in the near future to look into cocoon as well). Has anyone else had a chance to look at the changes that have occured in pluto? What are your thoughts? > > > In the end, I think the critical issue will be community: Pluto currently > > has > > a real stake in providing a light portal since it's required for it to > > deliver > > its second main use case (portlet development testbed) whereas Jetspeed has > > less an incentive to do it (the community rather tends to add feature than > > keeping it small and simple). > > > We are adding new features all the time, true, however, features are > added within the context of pluggable component solutions. > > One of the most distinguishing features of Jetspeed is the component > model with ISVs in mind. It is the basis of the Jetspeed philosophy to > be able to assemble and plug-in components to specific target, be it a > heavy-weight full featured enterprise portal or a light-weight embedded > portal. > > Examples of embedding and specialized solutions: > > * Jetspeed-2 running embedded inside Jetspeed 1.6 > * Jetspeed-2 running embedded inside Jahia Portal > * Jetspeed-2 running on top of JBoss dedicated for a specific purpose > (http://wfmopen.sourceforge.net/) >
