forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Forrest TODO list
Date Wed, 01 Jan 2003 13:53:37 GMT
Hi,

Hope you all had a good break.

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.

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 :)


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   [core.store.persistent] (/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>(IndexedObjectDatabase.java:88)
  at org.apache.cocoon.components.store.JispFilesystemStore.initialize(JispFilesystemStore.java:237)
  at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:275)
  at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(ThreadSafeComponentHandler.java:98)
  at org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(ExcaliburComponentManager.java:513)
  at org.apache.cocoon.Cocoon.initialize(Cocoon.java:288)
 

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 'forrest.skin' and other properties to the sitemap, so we can
  avoid the @skin@ hack, and a bit of forrest.build.xml 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 forrest.iguanacharlie.com 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] http://marc.theaimsgroup.com/?t=104065768300003&r=1&w=2
[2] http://marc.theaimsgroup.com/?l=forrest-dev&m=103975237116577&w=2
[3] http://marc.theaimsgroup.com/?t=104099660500001&r=1&w=2
[4] http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html

Mime
View raw message