On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown <a...@the-martin-byrd.net> wrote: > Rob Weir wrote: >> And I've added it to the wiki: >> http://wiki.apache.org/incubator/ODFToolkitProposal >> >> -Rob > > What can I do to help? >
Good question. Once the project is set up, there will be many areas where we would benefit from contributions. Naturally, this includes Java programmers, but also QA, documentation, and of course, users. Some specific things that I think would be interesting, if we had more contributors: - Work on improving the JavaDoc. What we have now is thin and would benefit from editing by someone with English fluency. - Quantify our unit test test-coverage and write additional targeted unit tests so that we achieve 100% coverage - A module that takes an ODF document as input and generates code, expressed in the ODF Toolkit, that would when executed created the original ODF document. It sound weird, but think about it. This would allow someone to jump-start a program that produced customized versions of that document. - Implement OpenFormula, the spreadsheet formula language of ODF 1.2 - We occasionally get a report of concurrency bugs. These, as you may know, are notoriously hard to debug and fix. Is there something we can be doing to shake out these errors earlier, during test? What is the state of the art here in static and dynamic analysis? - We have a "cookbook" [1] of sample snippets of code that illustrate common problem/solution pairs, like how to copy a slide from another presentation deck. This cookbook is very useful and popular. But there is much room for expansion. - Performance -- profiling and tuning is needed. - A more radical way to achieve greater performance would be to have a streaming-mode API that does not require building a DOM at all. This would be limited in what you can do with it -- especially limited to what can be done within a single pass over the document -- but could be highly optimized. For example, suppose you just want to extract the author's name and creation date from a large number of documents. This requires only that you scan through the meta.xml in the ODF ZIP file. Building a DOM would be highly wasteful. But if you had a SAX-like set of listener interfaces and realized that only a MetadataListener was registered, then you could optimize the processing of the document. So, there is no shortage of areas were we could use help. And there are probably even more ways of improving/extending this code than I have even thought of. [1] http://simple.odftoolkit.org/cookbook/index.html > Andy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
