incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Let's discussion on the next release
Date Tue, 24 Jan 2012 22:39:27 GMT
On Tue, Jan 24, 2012 at 5:20 AM, Svante Schubert
<svante.schubert@gmail.com> wrote:
> 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).


OpenFormula formulas, at the schema level, are just xsd:string's.  So
to generate a parser we'd need to use a more generic tool, like JavaCC
or Antrl.  The OpenForuma spec does give some EBNF that could be used
to jump start the grammar definition.  On the other hand, the syntax
is simple enough that a hand-written parser would not be very hard.  I
think we managed to avoid ambiguities that would require look-aheads,
for example.

I like the idea of reusing things like Apache Commons math where we can.

> 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?

Perhaps for documentation purposes.  If you have a complex spreadsheet
model and want to review the calculations, to eliminate errors, then
it could be useful to generate a text document from the spreadsheet
that displays all of your calculations using standard mathematical
notation.  Perhaps.  I'm not aware of anyone who has done something
like that with spreadsheets, so I'm just speculating it might be
useful.

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

Well, it could be identical.  Or could be different.  It really
depends on the level of abstraction the app developer wants.  For
example, I might want something that scans the document and calls by
registered handler every time a hyperlink is found.  Another developer
might want every paragraph.  Another one might want only metadata from
meta.xml.  The value of the scanning approach is you can optimize the
scan based on what handlers are registered.  For example, if they want
only hyperlinks, then you don't even parse meta.xml or styles.xml.
The power of the approach what you can ignore.

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

It can get complicated rather quickly:

http://en.wikipedia.org/wiki/Operational_transformation

>> 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.
>

I think some projects are participating in a limited trial of git at
Apache.  Based on the results of that experiment, we might see it used
more broadly.

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

Mime
View raw message