incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: [PROPOSAL] ODF Toolkit for Incubation
Date Thu, 21 Jul 2011 12:28:46 GMT
On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown <andy@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message