incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svante Schubert <svante.schub...@gmail.com>
Subject Re: Let's discussion on the next release
Date Tue, 24 Jan 2012 10:20:35 GMT
On 24.01.2012 02:45, Rob Weir wrote:
> On Mon, Jan 16, 2012 at 8:12 AM, Devin Han <devinhan@apache.org> wrote:
>> Hi all,
>>
>> Thanks you for the contribution of the the first release! Now the plan of
>> the next release is on the desktop.
>> I summary some todo items and wish to get your guys' feedback.
>>
>> (1) Clear crypto process with Apache.
>> (2) Commit encryption/decryption code to the master repository.
>> (3) Update package name from "org.odftoolkit.*" to
>> "org.apache.odftoolkit.*".
>> (4) Remove ODFDOM Doc API which has been marked as deprecated in the first
>> release.
>> (5) bug fix.
>>
>
> Other things I'd be interested in working on are:
>
> 6) Implementation of OpenFormula, the ODF 1.2 spreadsheet formula
> language.  Perhaps even a reference implementation.
Sounds interesting. From the beginning I would aim higher in the design:
Certainly we all would use an existing Math library in the back-end, as
    http://commons.apache.org/math/api-2.2/index.html
generate ourself a parser from the schema and wire those two together
(using as much generation as possible).
While doing this, trying to use GWT (Google Web Toolkit) to get from the
Java reference implementation as well a JavaScript implementation for
OpenFormula usage in the browser.
Not easy, but a lot of reliable output for comparable little work.

Does an import/export of OpenFormula to mathml makes sense in this context?
>
> 7) A streaming API that is able to do a subset of operations on a
> document in constant memory, using a SAX-like event interface.
This streaming API is identical to a collaboration API. If two people
are collaborating: both starting with an empty document and one adds a
lot of content. Those change events sent to the other are similar to the
parsing events of a new document. This approach has even other
advantages. Let me tell you a story:
"I have once worked on a browser based ODF implementation. The former
straight forward approach was to transform the ODF to HTML on the server
and sent it to the client.
Unfortunately when adding new document content (e.g. new list items) the
client has to know exactly what HTML has to be inserted. This HTML has
to be identical to the HTML being generated on the server.
Long story short, we had a code dependency from server and client
sources, which added complexity and points of failure. As you when you
change one, you have to change the other as well!"
Therefore the better design is to stream the ODF document from the
server to the client similar as it had been generated from a different
user using collaboration.
Abstracting mapping details, keeping those responsible to all different
clients (browser, tablet, OOo, MS Office, etc.).
> Since these are new modules, they might not be doable for the very
> next release.  But I want to suggest them as possible areas of
> exploration, in case anyone else wants to help.
>
> Maybe for things like this, we can do the work on "feature" branches,
> so the trunk remains stable on a daily basis?
This sounds like a job for GIT, anyone has new information on the GIT
test project outcome? SVN is painful, when worked with Mercurial/Git before.

- Svante
> -Rob
>
>> --
>> -Devin


Mime
View raw message