On Sunday, Oct 12, 2003, at 04:23 Europe/Rome, Jeff Turner wrote:
On Sat, Oct 11, 2003 at 03:17:48PM +0200, Stefano Mazzocchi wrote:
On Saturday, Oct 11, 2003, at 14:25 Europe/Rome, Nicola Ken Barozzi wrote:
Please don't forget Forrest.
we are not.
:) Let's remember that there's hard reuse and soft reuse. Hard reuse
means physically integrating with Forrest/Lenya. Soft reuse means
reusing ideas, people, and code where appropriate. For a new project in
RT phase, worrying about hard reuse with Forrest and Lenya would IMHO
just slow things down.
I agree: try to come up with a system that runs first and *after* try to merge the results and possible changes back in the original systems. This reduces the potential community friction when changes require some little paradigm shifts.
Forrest started with a RT, a mailing list, and a bunch of Cocooners
willing to contribute. I wasn't at the GetTogether. I've never seen a
RT articulating the vision for this project. There's just tantalising
snippets. Could we perhaps dream up a name ('linotype' seems obvious),
start a mailing list, and have some RTs on what this is all about? :)
That's what we are trying to do with this thread, Jeff, get a name, a collection of random thoughts and get going. I don't think we need a different list for now.
The things that were discussed at the hackaton were simply higher-bandwidth version of this conversation. And Bertrand started it over in order for everybody to know what were talked about and having the ability to jump in and help.
In case something is not clear, I'll be very happy to explain it.
I thought about it and I totally resonate with Bertrand: we need to outline an incremental transition to our own CMS reusing as much dog food as possible (which is also good for a community perspective).
Here is my proposal:
1) the system gets divided into three parts
- frontend -> mapped to http://cocoon.apache.org -> static - repository -> a WebDAV server - backend -> mapped to http://edit.cocoon.apache.org -> dynamic
The mozilla.org site does something similar, in that the 'edit this page'
link goes to:
http://doctor.mozilla.org/?file=mozilla-org//html/index.html
I've long thought this would be a great Forrest enhancement.
exactly. Zope does similar things as well.
It's been 3 years I wanted to implement this in cocoon (frontend/repository/backend architecture)... the incubation of lenya was instrumenting for this. also the creation of linotype (experimenting with serious editing, repository separation and numberical URIs).
the wiki forced me to realize it's now time to move on and the hackaton gave me a way to express myself clear enough so that others were tickled by it.
The future idea is to use indirect linking where lookup is a sort of "what's related" understood out of the analysis of user patterns, but this is far ahead in the future.
For now, I think direct linking would be enough for our needs... we just need a good "lookup and discovery" of learning objects integrated in the backend.
- o -
As the implementation
1) forrest will be used to generate the site from the contents of the repository
2) the repository can be either plain vanilla subversion or a webdav server implemented by cocoon on top of another repository (either subversion or catacomb or JSR170). even CVS, but we might want to stay away from it.
3) lenya will be used as the backend.
Missing things:
1) is forrest already capable of doing what we ask?
Possibly. Forrest's sitemap is built in layers:
cocoon://**.xml # Source pipelines generating doc-v12 cocoon://body-*.html cocoon://menu-*.html cocoon://tabs-*.html # Intermediate formats cocoon://**.{html,pdf} # Destination formats
So just switch in a different **.xml subsitemap, and Forrest will build the site from whatever backend you choose.
Sounds perfect.
Forrest's indirect linking system is (IMHO:) pretty cool and Wiki-like,
in that I can write <a href="site:foo"> from anywhere, and it links to
the 'foo' page wherever (or whatever) it is. The source files have a URI
space all of their own, independent of the final http: URI space.
Very good as well.
The linking implementation is very flexible, built in input modules. <a
href="site:index"> causes the 'site' InputModule to be fetched and passed
the 'index' key. A SimpleMappingModule converts this to
'/site//index/@href', which is fed to an XMLModule, which interprets it
as an XPath into the navigation file, site.xml. As the XPath prefix and
suffix are configured in cocoon.xconf, any XML format for the 'linkmap'
(aka site.xml) can be used. Lots of gory details at
http://xml.apache.org/forrest/linking.html
As you can see from my question, I (and possibly many others here) lost contact with forrest a while ago: you people simply did the job well enough for us crawl back in our corner as simple users ;-)
but as you suggest, we might need "soft reuse" at this point, so you'll hear from us when things don't work (or you are more than welcome to join, of course).
2) what's the best repository? where do we install it?
3) is lenya enough for what we need? (Michi says so)
4) how much work is the integration of linotype with lenya? (I'll investigate this soon)
5) how do we get the wiki into the repository? (I plan to write a wiki-syntax editing pane for linotype, would this be enough?)
Could use the Chaperon Wiki grammar to convert to XML, but..
grammar-based validation results in really undecipherable error messages.
Might be best to first use a regular Wiki engine as a 'lexer', to get the
Wiki syntax 'well-formed', and then use a grammar to go from well-formed
Wiki -> XML, and then use an XML schema to ensure validity. 3-phase
validation of Wiki syntax. Could warrant a project all on its own..
yeah
6) how do we get the rest of the data into the repository?
7) how do we make it simple to edit linkmaps? what searching and proximity tools can we provide for this?
Lenya is probably the best hunting-ground for this.
yep, forrest as the frontend engine, lenya as the backend engine, cocoon empowering both, documents all safely stored in one repository (no more CVS branching for docs!!), easy editing, easy workflow, ability to assemble trails of documentation, no need to bug infrastructure@ for a dynamic site, mirror friendly...
... gosh, seems like heaven ;-)
-- Stefano.
