incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devin Han <devin...@apache.org>
Subject Re: Merge of ODFDOM DOC package and Simple API
Date Mon, 26 Sep 2011 06:30:02 GMT
2011/9/23 Svante Schubert <svante.schubert@gmail.com>

> Am 23.09.2011 05:27, schrieb Devin Han:
> > 2011/9/23 Svante Schubert <svante.schubert@gmail.com>
> >
> >> I agree with Devin to do the merge of Simple API and the ODFDOM Doc
> >> layer before the next feature release.
> >>
> >> Thanks for your support ;)
> > At least, we can remove the ODFDOM Doc layer.
> > Lots of bugs in it, user should drop it and turn to Simple API.
> >
> Careful with the claim of bugs, it might backfire as we wrote that code
> together. ;)
>

Doesn't matter, you can see how many bugs are fixed and how many new
features are added after Simple splited from ODFDOM ;)


> Nevertheless I agree to favor Simple API.
> It just took a little longer to understand that with 'merging with DOC
> layer'  you meant 'deleting the DOC layer'.
> The DOC layer is a superset in regard of functionality and especially
> the tests should be reviewed if they might help us to archive a better
> coverage.
> In our first no-functionality-change release we should keep the doc
> layer and mark/document that layer as deprecated.
>

I prefer to give user a more clean library. No deprecated, just removed. We
can supply a document to explain it, just as we have done in ODFDOM, see:
http://incubator.apache.org/odftoolkit/odfdom/ReleaseNotes.html.  What's a
big change, isn't it?  For these changes, I insist that we do it in the
start.
Users have the most tolerance for the first release.

On the other hand, I did the split work between ODFDOM and Simple API. I
know it's easy to merge them. Why not we do it now?

Apache is a new start for us. We shouldn't fear change, but should fear we
can't supply a clean, stable and easy used tool to users!  For this, we need
a clean and stable code base!

Anyway, ODFDOM Doc Layer must be remvoed and replaced with Simple API in the
first release.




> >> One think I have observed, that the Simple API removed the Automatic
> >> Styles from the high-level layer, which is the right decision, but did
> >> added user support for style maps into the lower layer, which made the
> >> usage really difficult.
> >>
> > No, Simple API doesn't do anything on Automatic Styles... It's the work
> of
> > ODFDOM. When we adopted to ODFDOM0.8.7, we did updated some code
> concerned
> > with Automatic Styles. But it caused by ODFDOM updated, not Simple.
> >
> How does the Simple API mark allow the user to access formatting that
> are not part of a named style?
> For instance, mark some text as bold or change the color.
>
>
> >> This could be solved by
> >> https://issues.apache.org/jira/browse/ODFTOOLKIT-182
> >>
> >> Any comment on this?
> >>
> >> Svante
> >>
> >
> >
>
>


-- 
-Devin

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message