On Fri, Jul 13, 2012 at 6:11 PM, Steele, Raymond <[email protected]> wrote: > Graham, > > Thanks for the info. I've never heard of LibreOffice until today. We > currently have StarOffice installed on our Solaris systems. Do you know if > Oracle is still developing StarOffice? It appears the Open Office is still > being developed under Apache. >
Oracle stopped working on OpenOffice in 2011 and contributed it to Apache. It is now Apache OpenOffice, and the most recent version, 3.4.0, was released in May. Next release is expected at the end of July. More info at: http://www.openoffice.org Of particular interest, there is a some progress on a Solaris port of Apache OpenOffice. Read more here: https://blogs.apache.org/OOo/entry/porting_apache_openoffice_to_solaris AFAIK, no one is continuing development of StarOffice (Sun's old commercial version of OpenOffice). Though IBM (my employer) has stated that it plans an "IBM Edition" of Apache OpenOffice at some point. -Rob > -----Original Message----- > From: Graham Weatherup [mailto:[email protected]] > Sent: Friday, July 13, 2012 11:28 AM > To: [email protected] > Subject: RE: EXTERNAL: RE: Database base odb support > > OpenOffice.org is one of the leading competitors to the Microsoft Office > suite of business productivity applications. Originally developed as > StarOffice in the late 1990s, the suite had been managed in recent years by > Sun Microsystems as an open source project. But when Oracle acquired Sun in > April 2009, the future of Sun's software offerings -- particularly free ones > like OpenOffice.org -- was called into question. Before long, key > OpenOffice.org developers, unhappy with the status quo under Oracle, began > defecting from the project. > > The result was LibreOffice, a new fork of the OpenOffice.org code base that's > maintained by a nonprofit organization called the Document Foundation. > LibreOffice looks like OpenOffice.org and it runs like OpenOffice.org. It > even reads and writes OpenOffice.org's OpenDocument file formats. The > difference is that LibreOffice is being developed in a fully community-driven > way, without oversight from Oracle. (The "libre" in the suite's name is > derived from a Latinate root meaning "liberty.") > > Source: > http://www.infoworld.com/d/applications/open-office-dilemma-openofficeorg-vs-libreoffice-716 > > From my very limited experience LibreOffice development seems more active and > the development help more helpful. > > Graham > > -----Original Message----- > From: Steele, Raymond [mailto:[email protected]] > Sent: 13 July 2012 19:04 > To: [email protected] > Subject: RE: EXTERNAL: RE: Database base odb support > > 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 >> > >
