Hi again, Frank, Am Dienstag, den 18.09.2007, 21:43 +0200 schrieb Frank Schönheit - Sun Microsystems Germany: > Hi Marc,
> > An idea here could be to re-package the .odb using the database part as > > a single item with compression -0, but I think zip doesn't support this. > > It does. The meta information in all of OOo's document is uncompressed, > for quicker access. However, still the complete package has to be > written when you only change a single byte. At least one possibility. If a scheme of temporarily writing to a random access file and adding the (closed) ra-file to the zip when closing the .odb would be introduced. > > But using ODF for the database part is debatable in itself, there is no > > application that could reuse it currently - and reuse is the goal of > > ODF. > > Well .... if we do *not* embed data (and there are people somewhat more > affiliated with ODF which say data embedding is not the goal of ODF), > then it is reasonable. ODF 1.2 will probably include a standardization > of the database description, which could also be used by Kexi, for instance. > > So: ODF doesn't exclude reusability per se. That's an interesting thought, if you say the ODF file only will contain the metadata and the real data is stored in an (not completely, see above) external high performance container file. > > So having a random access file backend would be the way to go. Do you > > have something in mind (although I think this has to be solved in the > > HSQL source)? > > I don't. There is not standardized random access RA file format which > would have a remote chance of being accepted by OASIS for this purpose. > Well, there are Microsoft's storages, which provide a virtual RA file > system inside a single file. All Microsoft binary formats use such > containers, IIRC StarOffice's old binary formats did, and so there even > is an implementation in OOo for reading/writing them. However, this > format also has shortcomings, and probably also not good chances at OASIS. > > No, I think we need to use some kind of proprietary file format for > this, if we ever want to get this in a reasonable time. Where > proprietary can still mean open (and only "not standard"): We could > implement something on our own in OOo, or in the DB backend (yes, the > HSQL source, in this case). In both cases, there would be a lot of > politics and hot discussions involved before we would be allowed to use > such a non-standardized format. > In general, I can understand the problems with such a non-standard > format: It contradicts the whole story of OOo's standards-affiliation. Since it is my personal pet for storing hirarchical measurement data I could imagine HDF5 as a portential candidate. It is - mature - cross platform (with respect to endianness and more) - ported to many existing platforms - has a table-style api (and images, too) - fast - has a tool for exporting the contents of a hdf5-file to XML (h5dump) - can store hierarical data and has the capability of storing metadata/attributes for stored items - it is actively developed by people knowing their craft Have a look there: http://www.hdfgroup.org/ and for an impression you could search for "PyTables" (no link, sorry) which is an adaption of the table api to python. > On the other hand, there is no other solution if we really want scaling > one-file DBs. > > > <shouting "Jehova mode> > > Other databases using binary files having a jdbc driver may fit this > > requirement, too. Firebird would be a candidate. > > </shouting "Jehova mode> > > Sure. Do you volunteer to write the driver/integration for FB? :) No, definitly not. That's why I tagged this remark with some sort of "humor sign". ;) Although I'd appreciate having drivers for Firebird, DB2 and other would be nice, this is far beyond the scope of my time. How much work would it be to write a driver? Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
