ODF Toolkit/Minutes/2008 06

From Apache OpenOffice Wiki
Jump to: navigation, search


[Fri:09:31:01] <DL> ===============================================
[Fri:09:31:03] <DL> AGENDA:
[Fri:09:31:04] <DL> 1 Status of the Teams
[Fri:09:31:06] <DL> 1.1 ODF4J: Bernd Eilers (rfc821), Amit (amitksaha)
[Fri:09:31:07] <DL> 1.2 AODL: Lars Behrmann (lb),liuyuhua
[Fri:09:31:09] <DL> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
[Fri:09:31:10] <DL> 1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
[Fri:09:31:12] <DL> 2 Open discussions
[Fri:09:31:13] <DL> ===============================================
[Fri:09:31:15] * dy1 has joined #odftoolkit
[Fri:09:31:18] <DL> 1.1 ODF4J: Bernd Eilers (rfc821), Amit (amitksaha)
[Fri:09:31:40] <DL> seems that we will get no update today
[Fri:09:31:55] <DL> 1.2 AODL: Lars Behrmann (lb),liuyuhua
[Fri:09:32:05] <larsb_> Nothing really new. Next week I'm going to discuss the style handling for ODFDOM with Svante and I won't start refactoring AODL before we don't have clarified that.
[Fri:09:32:37] <DL> ok
[Fri:09:32:44] <DL> 1.3 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
[Fri:09:33:10] <DL> no update, too
[Fri:09:33:21] <DL> 1.4 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
[Fri:09:33:59] <DL> no update
[Fri:09:34:12] * amaOOo has joined #odftoolkit
[Fri:09:34:38] <DL> AMA: any update from you?
[Fri:09:34:57] <liutao> no
[Fri:09:35:03] <amaOOo> Resync to m18 is done, automatic test started
[Fri:09:35:30] <DL> ok, thanks.
[Fri:09:35:34] <DL> 1.5 ODFDOM (Svante, etc.)
[Fri:09:35:41] <fme> Svante announced a new version of ODFDOM (0.6.4). ODFDOM now does not require JDK6 any longer but works with JDK5. I think the mercurial repository will be available for public use soon. There's also a fix for a regression with temporary directories and some other minor bugfixes included.
[Fri:09:35:56] <larsb_> During the week we had a little ODF developer meeting here in Hamburg. Where Svante gave an presentation on ODFDOM what's it, how it works, ...
[Fri:09:36:03] <larsb_> Of course, we saw and heared presentaions about other odf api as well (mostly python) and discussed with their developers what know how could be shared, their experience while implementing ODF as an API, possible benefits which they would have by using also the ODFDOM approach, ....
[Fri:09:36:46] <DL> sounds good!
[Fri:09:37:23] <DL> more on ODFDOM?
[Fri:09:37:37] <fme> Not from my side. Klemens?
[Fri:09:37:45] <Klemens> no not from me
[Fri:09:38:05] <DL> 2 Open discussions
[Fri:09:38:19] <larsb_> BTW. We saw that their is a large request on script based languages mostly that used by web apps like python, perl, php ...also
[Fri:09:40:09] <larsb_> Most of the solutions we saw are based on the idea to generate or manipulate ODF Docs in CMS systems
[Fri:09:40:28] * odf-mib has joined #odftoolkit
[Fri:09:40:31] <larsb_> Plone, Drupal, .....
[Fri:09:42:09] <DL> good to know, that's exactly what we have expected :-)
[Fri:09:42:24] * bei has joined #odftoolkit
[Fri:09:45:41] <larsb_> Another request was to have, if possible, no further dependencies on other components or languages, just a plain ODF API in the used programming language
[Fri:09:46:27] <larsb_> For special requests, some also used UNO to use OOo as a converter
[Fri:09:47:42] <larsb_> Next to UNO they also mentioned SWIG as an wrapper to achive language bindings
[Fri:09:47:55] <DL> does that mean that we should have different APIs for all supported languages?
[Fri:09:49:26] <larsb_> I would say yes. Most web hosters don't offer the possibility to use Java and another benefit would that the developer don't have learn something new
[Fri:09:51:35] <DL> but how could we put an UNO API on this when all language-depended APIs are different?
[Fri:09:52:10] <bei> For the java language binding there is the requirement to use the org.w3c.dom.* APIs because otherwise we wouldn
t have a DOM API at all. [Fri:09:52:24] <larsb_> Not on the existing ones they are extremly different ....
[Fri:09:52:46] <DL> odf-mib: what's your take on that?
[Fri:09:52:56] <bei> Cant we just look on which enhancements we would have to make to UNO to achieve better language bindings?
[Fri:09:53:04] <larsb_> We should generate ODFDOM for Python, Perl, PHP, ...
[Fri:09:53:32] <DL> and we do not have UNO binding for all...
[Fri:09:54:01] <larsb_> I think we will get a lot of positive feedback and hopefully a lot of additonal contributors
[Fri:09:55:02] <odf-mib> I did not hear a request for an UNO API, but the demand to have a framework that allows to do some often used tasks.
[Fri:09:55:41] <odf-mib> One example is the creation of an index. That's a complex tasks, and most toolkits use OOo for this.
[Fri:09:56:38] <DL> sorry, but I have to leave.
[Fri:09:56:46] * DL has quit IRC ("ChatZilla [Firefox]")
[Fri:09:57:18] <larsb_> Whereby not the index is the problem, that could be solved through conevenient code in an ODFDOM api the problem are the page numbers in a TOC
[Fri:09:57:52] <odf-mib> Yes, I agree
[Fri:09:58:55] <odf-mib> But because of this, you probably don't want to have multiple implementations for this, but a single one.


<Malte> AGENDA:1 Status of the Teams1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian1.2 UNO based Toolkit: Juergen Schmidt (jsc), Jirong1.3 AODL: Lars Behrmann (lb),liuyuhua1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf2 Open discussions
Svante (n=sus@sd-socks-197.staroffice.de) has joined #odftoolkit
=-= Svante is now known as Svante_afk
odf-mib (n=chatzill@nat/sun/x-ade89e05f204afa6) has joined #odftoolkit
<Malte> 1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
=-= Svante_afk is now known as Svante
<amaOOo> Automated tests on swrefactor07105 showed some problems
<amaOOo> We decided to resync the CWS again to the newest milestone because
<amaOOo> the old milestone of the CWS had some problems in automated tests, too.
<amaOOo> The resync is done, Linux and Solaris build are available for automated tests.
<Malte> 1.2 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
<Malte> skipping...
<Malte> 1.3 AODL: Lars Behrmann (lb),liuyuhua
<larsb_> no news
<larsb_> .
<Malte> 1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<Svante> We have now delivered ODFDOM 0.6.2, which is finally fully JDK 5 compatible and contains several fixes and enhancements.
bei (i=rfc821@e177199162.adsl.alicedsl.de) has joined #odftoolkit
<dyf> nothing from me.
<Svante> There will be a version with a mercurial repository downloadable soon so we can use Mercurial patches in the future
<Svante> Soon means hopefully later this day..
<Svante> Happy and surprised about the count and quality of patches delivered last week
<Svante> Everything else was already mentioned on mail. Are there questions?
<Svante> BTW Netbeans 6.1 has a very nice..
DL (n=chatzill@nat/sun/x-67c27164cab91b97) has joined #odftoolkit
<Svante> optical diff mechanism for patches and creates them eaisly
<Svante> Any comments?
<Malte> downloading mercurial repositories sounds strange to me...What's the long term plan wrt mercurial support on OOo/Collab?!
<bei> currently rest of OOo wants to migrate to SVN first and than later on re-evaluate usage of a distributed repoository
<jdeisenberg> purely out of curiosity, why the choice of Mercurial rather than "git"?
<Svante> I will meet Martin Hollmichel today and discuss it, but downloding Mercurial is not strange it is explictly made of OFFLINE usage
<larsb_> git -> no good tools for windows developer
<Svante> I do not know git in detail, but many other projects (Mozilla, OpenJDK, Netbeans..) moved to Mercurial
<Svante> I have not made the decision, but I am quite happy about it, the more I learn about Mercurial
<jdeisenberg> OK. i was just wondering. I had heard good things about git also.
<Svante> Hopefully there will be soon a online access the sources as well
<Svante> ..and not to forget a issuetracking tool like Bugzilla
<larsb_> Most of the mercurial code is written in Python so its no problem to run it on other plattforms. Additional the integrated Mercurial support of netbeans is a big benefit ;)
<Svante> Yes, aside of commit/etc, it is quite easy to import/export and view patches with Netbeans
<Svante> Next week I will start working on the generation of all ODF elements
<bei> There´s some discussion about what the OpenOffice.org community will be using in the future, I think it´s a good thing to experiment with on subprojects that are not part of the OpenOffice.org product at this time.
<larsb_> You man saturday and sunday ? :)
<larsb_> man ->mean :(
<Svante> ;-)
<Svante> This generation is essential for a style.xml DOM, which currently not exist
<Malte> I assume "online access the sources" is more about a source browser...Long term support for mercurial on Collab is not answered for me.Downloading repositories, instead of pulling and pushing. Is this really the way to handle it?And when there is no mercurial infrastructure on collab.net - who will update the browsable sources?
<Svante> Why don't you ask Martin? ;-)
<Malte> Because you introduce mercurial here...
<Svante> Because I meantioned that I will have a chat with Martin today, do not ask the result ahead of the meeting, Malte
<Malte> Uuups - didn't read that...
<Svante> hehe
<Svante> Anyway I am happy that we are making progress ;-)
<jdeisenberg> A styles.xml DOM will be very nice; creating a <number:date-style> was not fun.
<Svante> I believe and thanks for the patch
<jdeisenberg> so I will welcome that addition.
<Svante> We will move most of the existing styles in the convinient level
<Svante> And the automatic styles handling have to be refactored
<Svante> But this will happen after the generation.. One step after the other..
<jdeisenberg> I have an idea about styles in the convenience level; I'll wait for open discussion part.
<Svante> We should start this part.. I am through...
<Malte> Open discussions then...
<Svante> Finally.. ;-)
<Svante> What is your idea, David?
<jdeisenberg> To create a <number:date-style> from a format string like the UNIX date command
* Svante is opening the OpenDocument specification
<bei> There´s been the idea on the mailing list to separte API from implementation by using interfaces extensivly and I just want to support this idea big +1 from me for doing this.
<jdeisenberg> or whatever format string you like.
<jdeisenberg> thus, something like:
<jdeisenberg> dateStyle = dateStyleFromFormat( "%Y - %m - %d");
<jdeisenberg> would create an XML fragment (or internal representation) with all the subparts of the <number:date-style> as they should be.
<fme> jdeisenberg: I suggest this would go into the convenient layer of ODFDOM.
<fme> jdeisenberg: Would you like to implement this function?
<jdeisenberg> or better, use the SimpleDateFormat rules, since Java programmers already know them.
<jdeisenberg> I can certainly give it a try.
<Svante> +1 sounds like a nice idea
<fme> jdeisenberg: Fine.
<Svante> bei: Regarding the interfaces, I will reply to the mailing list asthe meeting is nearly over
|<-- DL has left freenode ("ChatZilla [Firefox]")
<Svante> For some it has already ended.. ;-)
<jdeisenberg> but I don't think I can write the code before I leave for my trip on Sunday.
<Svante> Not a problem at all
<larsb_> i have to leave for a meeting, bye
<Svante> Anything else to discuss now, otherwise I would suggest we continue next week or on the mailing list
<Svante> Right, so thank you very much for coming!
<amaOOo> Bye bye!
<--| amaOOo has left #odftoolkit
<Svante> See you all next week and happy coding!
<Svante> byebye
=-= Svante is now known as Svante_afk
<fme> Bye all.
<--| fme has left #odftoolkit


<Malte_> AGENDA:1 Status of the Teams1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian1.2 UNO based Toolkit: Juergen Schmidt (jsc), Jirong1.3 AODL: Lars Behrmann (lb),liuyuhua1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf2 Open discussions
<Malte_> 1.1 Modularization, SW: Andreas Martens, LiuTao (liutao), lijian
<xiuzhi> Li jian is on vacation ,as you know, the Dragon Boat Festival is coming.
<amaOOo> We are currently organizing QA for our CWS swrefactor,
<amaOOo> first automated tests and afterwards manual tests
<Malte_> liutao: Anything to add?
<liutao> no
<Malte_> 1.2 UNO based Toolkit: Juergen Schmidt (jsc), Jirong
<Malte_> skipping...
<Malte_> 1.3 AODL: Lars Behrmann (lb),liuyuhua
<larsb_> no news today
<larsb_> .
<Malte_> 1.4 ODF4J/ODFDOM: Bernd Eilers (rfc821), Amit (amitksaha), Svante, Klemens, dyf
<bei> no news today
Jirong (n=Jirong@ has joined #odftoolkit
<Jirong> hi, all
<larsb_> Frank and I took a look the current ODFDOM style handling and thought about how to make the style handling easier
<dyf> I 'm trying to move form to convenient layer.
liuyuhua (n=amaze_li@ has joined #odftoolkit
<larsb_> We have some ideas, but will first discuss them with Svante next week
<Malte_> That's all on ODFDOM?
<larsb_> nothing more from me
<Malte_> Jirong: Anything on "UNO based Toolkit"?
<Jirong> nop, there is no progress
<Jirong> I am currently working on Developer's guide (Chinese) Wiki page
<Malte_> OK, seems we are done then.....
<Jirong> the UNO based Toolkit is on kind of suspend status
<bei> We had some complaints about odfdom requiring jdk6 and not being compatible with jdk1.5 it´s only 2 lines of code requiring jdk6 and I think we should change them!
<larsb_> Correct until now its only 2 parts in the code and for now we could change them
<liuyuhua> larsb: hello! larbs, how about the project of the aodl?
<larsb_> one moment I'm just writing the rest on bei question, thanks
<larsb_> bei: but I'm not sure if we can promise that jdk 1.5 will be supported when have implemented the rest of the convenient layer ... we should discuss that with svante next week also
<bei> ok
<larsb_> liuyuhua: At the moment I'm still analyzing the best way of moving the AODL architecture to this of ODFDOM
<liuyuhua> larsb: if you have some work to to , you can ask me to do that and send me a mail ,:)
<larsb_> liuyuhua: There is so much convenient/useful code which I want to reuse
<larsb_> liuyuhua: Thanks, of course I will do that :)
<larsb_> liuyuhua: BTW what you already can do is to take a look at the architecture of ODFDOM. The the nodes and documents handling will be equal ;)
<xiuzhi> Malte_: It seemed that UNO API project was suspended. Do you know the reason?
<Malte_> Sorry - you will have to ask Juergen...IMHO it's because Juergen had other urgent things to do.
<xiuzhi> Malte_:ok
<liuyuhua> larsb: ok .
<Malte_> OK, time is over, I think... :)
<Malte_> See you next week - bye
Personal tools