My response will bring no value to the subject, but I thought I'd ask. What is the difference between OOo (OpenOffice??) and LibreOffice?
Raymond -----Original Message----- From: Graham Weatherup [mailto:[email protected]] Sent: Friday, July 13, 2012 10:57 AM To: [email protected] Subject: EXTERNAL: RE: Database base odb support Hi Rob, Thank you for your help. Our software (PAMGuard.org) is used to process acoustic data and output results to database. Tables hold information such as GPS data, audio file data then outputs from the processing of the files. We do allow storage to serialised binary files for data which is just being used PAMGuard but people like data output to database(currently access or mysql) so they can work on it for their own analysis of the output and so they can share the data easily. There are several reasons we would like to include .odb support. There are good free GUI editors that people can work with. OOo and Libre (I have not found such good editors for SQLite and most of our users are not SQL savvy but want to be able to run queries etc) Being able to use pure java hsql driver should allow for 64 bit support for extra RAM usage. Giving the option of in-RAM databases may increase speed which should be possible with hsql Single files are easy for our users to send to each other. Below is the response I got from LibreOffice mailing list suggesting ODFToolkit. For the fastest implementation all I need to work out is the zipping issue of mimetype etc and if any other file get edited. However if I had the expertise I would much prefer to write the abstraction layer you talk of but I really don't have enough knowledge or understanding of even writing on top of ODFDOM to do something like that. From what I hear OOo works by working on the database and polling changes to the Zip(odb) file so data is not lost during a crash. Extracting it is more clumsy and risky but it get a working solution. The ODF toolkit must be able to at least deal with the zipping issue I mean in that it must be the same in odt/ods files. Graham >>>>>>>>>>>>>>>>>>>>>>>>>>> hi Graham, On 09/07/12 16:53, Graham Weatherup wrote: > The above link also directs to a description of how to unzip it in > java** so I figured I should be able to zip the files up and open it > again with Open Office. When I zip the files with java.util.zip using > the method here*** the file called ‘mimetype’ comes out “compressed” > but actually bigger and even setting compression off in the its still > bigger but not as much 41bytes vs 43bytes (I don’t remember the > numbers > exactly) but not the 39bytes that is required. Also I read on a linux > forum that I cannot find that mimetype has to be ‘at the beginning’ of > the file. > > Also I wonder if there are any files that should be updated if tables > get added etc. any other files in the ODB file? > >* >http://programmaremobile.blogspot.co.uk/2009/01/java-and-openoffice-bas >e-db-through.html >** >http://digiassn.blogspot.co.uk/2006/07/java-creating-jdbc-connection-to >.html >*** >http://www.crazysquirrel.com/computing/java/basics/java-directory-zippi >ng.jspx >**** >http://www.oooforum.org/forum/viewtopic.phtml?p=257220&highlight=#25722 >0 there are very specific requirements on the "mimetype" file that are likely difficult for generic zip libraries etc.; note that there is an ODFDOM project that is a Java library that supports the ODF package specification directly so it makes this kind of thing much easier (it will also maintain the manifest automatically for you); it is now part of the Apache ODF Toolkit project. http://incubator.apache.org/odftoolkit/ if you use a generic zip library then you should really read the ODF 1.2 part 3 specification to understand the special requirements. i'm not familiar with the database part of ODF, but i could imagine it contains meta-data like column descriptions and such; for details refer to ODF 1.2 part 1 specification. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office >>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message----- From: Rob Weir [mailto:[email protected]] Sent: 13 July 2012 13:38 To: [email protected] Subject: Re: Database base odb support On Fri, Jul 13, 2012 at 6:17 AM, Graham Weatherup <[email protected]> wrote: > I was directed to this toolkit by Michael Stahl from the LibreOffice > dev list and would really like to use it for our java application > PAMGuard. I assume it will maintain support for LibreOffice and > OpenOffice as the files are the same? > I theory, yes, since ODF is a standard and the ODF Toolkit is based on the standardized schemas. At the lowest level the Toolkit code is machine generated from the schemas themselves, so it is a very faithful implementation of the standard. > I don't see any example/demos for databases or anything like > DatabaseDocument in the Simple API. > > Having looked at the source code I see the package > org.odftoolkit.odfdom.dom.element.db has a lot of database related classes. > > Is this something that is planned for development, side-lined or > actually working? If it is working are there any demos/examples that I > can use or can someone briefly explain how to use it? > I'd be interested in what kind of scenarios you would want to support with database documents. As you've probably seen, the API is in layers. At the lowest level is the code generation and package support. Then ODFDOM, which maps 1-to-1 to ODF schema elements. In theory you can do anything you want at this level, though you do need to know ODF well. And at the top level, in terms of abstraction, is the Simple API. This is a higher level wrapper of document manipulation functionality. So if your goal is simply to solve an immediate problem, then writing on top of ODFDOM is the fastest route. One useful application pattern is to start with an ODF document that was manually created in OpenOffice, and then write ODFDOM code to modify that document. This way generally requires a lot less coding than creating a document from scratch in code. On the other hand, if your goal is to create an SDK to enable others to create applications more easily, then writing an abstraction layer in the Simple API might work better. Regards, -Rob > > > Thank You > > Graham Weatherup >
