Hi Marc, > And since ODF dictates this approach it is implicitly excluding high > performance on bigger data volumes.
As long as ODF insists on ZIP as container format, and as long as we're talking about frequent small writes: yes. > > 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. > 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. > 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. 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? :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
