forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Lenya may start using Forrest Plugins
Date Tue, 16 Nov 2004 23:42:34 GMT
El mar, 16-11-2004 a las 17:07, Ross Gardler escribió:
> Nicola Ken Barozzi wrote:
> > Ross Gardler wrote:
> >>>> This is a good question. Any of our more experienced Apache folk got

> >>>> advice/links here?

> > Since they are _Forrest_ plugins, we will develop them here. Lenya 
> > developers are encouraged to take part in the discussions here, and in 
> > any case we will ping them when we believe that we have found a 
> > solution, so that they can validate the design.
> >
>  
> > In the future there may be a common plugin repository, but first we need 
> > the spec and some relatively stable implementation.
> 
> Yes, I agree. At this time we are only looking at integrating input 
> plugins. I am confident that the current solution for this is stable 
> enough, after all it is the most simple kind of plugin. I'm currently 
> extracting the MoinMoin functionality into a plugin so that we can use 
> that as a test case in Lenya. I'm resisting anything more advanced for now.
> 
> Ultimately, I would like to see Lenya as "just another" Forrest plugin. 
> By doing this Lenya gets all the Forrest features (which they have said 
> they want), and Forrest can be configured as a CMS using the Lenya 
> plugins, Lenya then becomes a specific configuration of Forrest and the 
> Lenya community is responsible for developing and maintaining the CMS 
> related plugins. What I learn from this (complex) use case will be 
> useful here at Forrest in designing the stable plugin infrastructure.
> 
> Am I I being to adventurous?
> 

:)

Ok, let me think out loud:

The current lenya core is quite big. Functionalities are in the core. 

Forrest started to use plugings to capsulate new *non-core* (or better
core implementation).

This would mean that lenya has to shrink his core and learn to use
forrest-plugin mechanism. Still lenya will want to have his own core, I
guess because it is a CMS. 

Lenya is a content management system (CMS) that supports the management
of content by providing tools for each phase of the content life cycle.
Lets focus first on definitions of content, content management and
content life cycle to get the big picture. 

Content
Content is every multimedial content independend of form (images,
text,sound,...), structure (description of the constitution of content)
and development state.

Content management
Content management is engaged in maintenance, updating and providing of
content. This will be done with tasks, which are necessary to control
and manage content within its life cycle stages.

Content life cycle
The content life cycle assumes that the content will cross different
stages from creating it to archiving it. These stages are enquiry,
production, review, release, publication and archiving of content.


The mission is to provide tools for each phase of the content life
cycle. Now lets try to draw a clear line between the differences of
forrest and lenya. 

Maybe by answering the following question it will be easier to draw the
line:

1 What is the mission statement of the forrest product?
2 What is the mission statement of the lenay product? see above ;-)
3 Where can we find overlaps?
Now both projects have in common that their are usinging extensively
cocoon.

4 What is the mission statement of the cocoon product?
5 Where can we find overlaps between forrest, lenya, cocoon?
Now all three have in common that they all want better documentation.
;-)
I read on all three list different ideas for *doco*. 

6 How can we use this information (5) strategical to leverage this
projects in terms of man power, knowledge and possibilities?


Maybe it is time to speak about an interface project that aims to
harmonize development between this three projects (to start with). 

The interface project (lets call it for the moment *doco*) should
provide a common basis for all interaction between this projects. It
also should hold the main documentation regarding each participant
project. It should be community driven from all three projects.

*doco* should be a screening agency for new concepts and ideas. It
should be as well an overseeing management committee to leverage man
power and knowledge. IMO our spec should be presented to the other
project to find ways to use this in those. 
*doco* should use the best concepts from each project and create a
common codebase for all three by following the simple principle of
"discussion, consens, documentation, ressourcen, roadmap,
implementation" when developing new code. This way the actual code that
will be implemented is already documented and has a project management
status.
*doco* should provide tools and functionality to help creating
documentation. e.g. the search provider script. It will contain
different service provider (e.g. lucene, google, dict.leo.org, marc,...)
that can be contacted for help in writing a documentation. It should
supply WYSIWYG editor.
*doco* should be able to extract information about mails in mailing
lists. Also it should provide IRC and extract documentation out of
chats. This way we will develope the code over eMail and irc and
documentate it in the same time by explaining it to somebody.
*doco* should support workflow and notification. 
...

I am saying all that because Nicola and Ross said
> > In the future there may be a common plugin repository, but first we
need 
> > the spec and some relatively stable implementation.
> 
> Yes, I agree. At this time we are only looking at integrating input 
> plugins. I am confident that the current solution for this is stable 
> enough, after all it is the most simple kind of plugin.

I reckon all the new concepts and spec can be revolutionary not only for
forrest, but as well for cocoon and lenya. I guess cocoon and lenya can
really profit from this concepts in using/enhancing/providing them as
well.

IMO we need a central place to discuss things about the interaction
between all apache projects. Besides that we should harmonize our apache
products and try to reuse/enhance existing documentation and code more
efficient. It is all about adding only product specific content and code
in an overall common base. The secret is to capsulate functions and
reuse them in different systems through plugins or publets. :)  

IMO it is important to discuss and explain our spec to lenya and cocoon.

To repeat Ross question: Am I being to adventurous? ;-)
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message