forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Forrest TODO list
Date Wed, 01 Jan 2003 20:26:17 GMT

Jeff Turner wrote:
> Hi,
> Hope you all had a good break.

yep & thx, before wishing forrest and all around a breakthrough 
in 2003 I'ld also like to thank this group for the work all of 
you havve been setting aside here and you Jeff, personally, for 
the way you have been active in this project the past months... 
quite some 'acorns' you've been dropping around :-)

I guess we all envy the time you can put into it, but even given 
that I still like to admit you'll spending it in a very 
productive way...

> I think it would be a good idea to get some sort of Forrest Roadmap
> happening, to figure out what needs to be done, what the priorities are,
> and who is willing to do what.

yep, I like this work-list aproach, hope you'll be feeding it to 
us again in apropriate portions in the running of the next 
months, and don't mind bashing people for things they take up and 
then leave behind (being quite good at that myself)

> Here is a list of things I can think of.  Please add to it, and indicate
> what you think is most important.  Maybe later we can break this up and
> add it to JIRA.  I think JIRA has XML export, so maybe we could create a
> 'todo' tab in Forrest, linking to each item.  Er.. add that to the
> 'medium term' list :)

- yep, in the same region (mid-term) would be some stylesheet 
(maybe together with some inputmodules stuff and config-file for 
the extra data) that allows publishing the status.xml as a 
rss.xml that people can aggregate in their blog-rolls (recent 
thought, people with experience or good pointers, throw them on 
the list please)

- also the edit-side of docs could use 'something' (really vague, 
I know, so put it on long term unless somebody can write down 
some sensible use cases)

- more nearby (mid-term?) something that makes the various 
book.xml's less of a hastle (and maybe settles down if libre is 
ever going to get somewhere or not)

- equally closer by I've sensed some emerging need for decoupling 
  the 1-1 between html and pdf (as printable version) typically 
people would like to aggregate some xdocs into one pdf (or 
straight print-nice html in fact) and/or split up a bigger 
document into multiple next|previous pages (given the fact that 
some were recently making the pdf for outside vs. html for 
interal distribution remark)

- on the forrestbot management web-gui: might be interesting to 
also be able to register new skins on there, and maybe web-form 
like submit or even edit a bot-config to add in the list.

as for the forrest-users mailing list: my feeling would be that 
committers still need to be subscribed to both anyway (and I'm 
lazy :-p ), so I would leave it to non-committers to actually 
raise the need (I mean when they start complaining about wasted 
bandwith on for them non-relevant stuff then it is probably a 
better time/argument than the 'we want to rant and flame in a 
more private corner' :-))


> Short term
> ----------
> - Fix or work around the images-in-PDF problem [1].
> - Fix the logging (logkit.xconf) to stop Cocoon generating 370k (!) of
>   logs per page rendered.
> - Fix whatever it is that causes Jisp to fill error.log with these:
> ERROR   (2002-12-25) 23:15.44:410   [] (/forrest/community/index.html)
Thread-13/JispFilesystemStore: get(..): Exception
> com.coyotegulch.jisp.DatabaseException: no indexes associated with this database
>   at com.coyotegulch.jisp.IndexedObjectDatabase.<clinit>(
>   at
>   at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(
>   at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(
>   at org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(
>   at org.apache.cocoon.Cocoon.initialize(
> Medium term
> -----------
> - Optimise the CLI to deal with Javadocs, and other large sets of
>   pre-generated content.  Apparently if Javadocs are placed in
>   src/documentation/content/javadocs, they will be traversed, but far too
>   slowly to be of practical use.
> - Figure out a way of traversing images specified in CSS.  Stefano's
>   suggestion [2] looks good.
> - Simplify the sitemap.  It is getting rather complex, and as the source
>   of Forrest's power we need it to be accessible to newcomers.
>   I'd suggest moving all the stuff specific to Forrest's site
>   (apachestats, community/revision stuff, libre, .dtdx, editor) out into
>   a Forrest site-specific sitemap.xmap.  Move anything else that can be
>   moved into subsitemaps.  Perhaps using XML entities to suck in bits of
>   sitemap would be a decent way to manage future sitemap complexity, at
>   least until Cocoon Blocks arrive.  Perhaps we can add XInclude support
>   to the sitemap?
> - Fix things so docs can be edited in src/*, and have the changes appear
>   immediately in the webapp.  Involves creating/using an InputModule for
>   passing '' and other properties to the sitemap, so we can
>   avoid the @skin@ hack, and a bit of hacking.  There
>   are some @tokens@ in a forrest-site CSS file that also need some sort
>   of in-place modification.  Perhaps a @token@-to-value Transformer could
>   be the same ${variable}-to-value Transformer mentioned in the RT [3].
> - Act on 'Entities in XML docs' RT [3].  I can implement Stefano's
>   suggested solution quite easily, but is such limited functionality
>   worth the cost of introducing a proprietary ${variable} syntax? Maybe..
>   Best short-term alternative seems to be using the XNI XInclude
>   processor for pre-validation inclusion.
> - Finish linkmaps, currently sitting in LINKMAP_BRANCH, I'd like to make
>   site.xml much more LSB-like, with file/folder element names and RDF
>   file metadata.
> - Skinify Miles Elam's CSS mockup.  The rounded
>   tabs would require the CSS image traversal fix, but it's not essential.
> - Schema issues.  There are lots of change requests (see
>   etc/DTD_DEFICIENCIES.txt) and an immediate need for some sort of DTD
>   versioning policy.
> - Docs.  A lot of the info on the website is outdated.  With metadata
>   from site.xml, it would at least be possible to indicate how old the
>   doc is, and perhaps indicate its relevance from a small controlled
>   vocabulary.
> Long-term
> ---------
> - Migrate to a decent schema language, primarily so that we can use
>   namespaces in XML docs, allowing things like XInclude, in-line metadata
>   [4], in-line SVG, Jelly snippets, or anything else users can make a
>   Transformer for.
> - Streamline the process of adding support for new schemas.  Ideally we'd
>   have an auto-download system, eg 'forrest-update docbook' would fetch
>   and install the Docbook DTDs, create catalog entries, sitemap mods etc.
> - Create a forrest-users list, so we can have flaming rows on forrest-dev
>   over arcana without annoying users :)
> - Create a Forrest Maven plugin.  This is probably the biggest single way
>   to widen Forrest's exposure and attract new users.
> --Jeff
> [1]
> [2]
> [3]
> [4]

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message