forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: Lenya may start using Forrest Plugins
Date Tue, 30 Nov 2004 01:50:45 GMT
Hi Thorsten:

Yes, you are being very adventurous!

Reading your mail I got some inspiration too. ;-)

Well, in my view:

1-Cocoon has nothing to do here. Cocoon only provides the platform for
both (Lenya and Forrest) that is all. Of course is posible to run both
using the same cocoon, but I guess this is OT here. And if some special
features are needed we can develop them. I expect the last will be
marginal of not required at all.

2-Lenya is the "content manager". On the other hand, Forrest can be viewed
as a content generator. The content generated by Forrest must be managed
by Lenya. In that way, we need to "attach" Forrest to Lenya and no the
oposite. That means we need to develop some tools that Lenya will use to
"know how" call the tools and Forrest need to provide a support for this
tools called by Lenya.

3-Forrest need to be able to generate only a desired document. Lenya will
"tell" Forrest wich one by running the forrest tools.

4-From Lenya can be posible to call Forrest in the same way as we call use
case. Here Flowscript can play an important role.

5-An interesting point to be solved is how to merge the Lenya "sitetree"
with Forrest site.xml and tabs.xml. Another posible solution is a
synchronization of all this files or perhaps we can "forget about the tabs
and site in the beggining and let lenya manage it. I am not sure if this
will be more easy or complicated. I am also thinking that another
posibility to include in this point the "linkmap.html" that forrest
currently generate.

                                -- 0 --

The other posible solution is import into Lenya some forrest plugins and
similar as above let Lenya manage everything.

                                -- 0 --

We need to start with a low profile if we want to make both work together.


Best Regards,

Antonio Gallardo

On Mar, 16 de Noviembre de 2004, 17:42, Thorsten Scherler dijo:
> 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,, 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)

View raw message