Hi Frank, Am Montag, den 24.09.2007, 11:30 +0200 schrieb Frank Schönheit - Sun Microsystems Germany:
> > VFS implementations capable of storing compressed files should be > > available in many incarnations - HDF is one. > > Built-in compression isn't even a requirement. I mean, for the DB > backend's data, I expect the engine to do (or not do, that is) > compression as needed. For embedded forms/reports, compression would > still be done in OOo, and the VFS would see the already-compressed data > only. For the remaining bits, "no compression" wouldn't really hurt, and > if it would, then OOo has own ZIP capabilities. Playing aroung with a .odb using internal hsql that has grown to a bit more than 12MB on disk it starts to get a little slow. Especially closing items (forms, tables, queries) takes some time, although the underlying table is rather small in size. Another spot where speed could help is when skimming through a table or query view page-wise. The farther to the end of the records it goes, the slower the screen update is done. But this is not so bad to be addresses at first. And closing the odb-file is really slow, as expected. Btw., making a report using the old, writer-based engine of about 20k record took *a lot* time, but I've been impressed by the resulting doc. It had 546 pages and was quite usable after loading, navigating pages, editing, all went fine. Even loading was slow but since the progressbar showed some action I could stand it well. :) Same holds true for base as an application. The last two weeks I've been testing a lot of stuff, form design, queries in design- and sql-mode and the like, with several databases and had not one single crash or noticable problem. Okay, when having the Basic IDE open and macros failed by empty object refs or so there seem to be some rough edges left, but the average user won't notice (will report when reproducable). Base has evolved a lot since the last times I used it extensively, well done! :D > >> Interesting. I'm not sure what our OASIS guys would say if I suggest > >> using a file format which, though open, is under the control of a single > >> company, but I will read a little. > > > > I never noticed that fact, hdf is around for many, many years. But if it > > is so the difference to OO.o or Java is not that big, is it? > > Neither Java nor OOo are standardized at OASIS. ODF *is*, and one part > of ODF is using the ZIP package format (which already a lot of members > had headaches with, as I've been told). > OOo is only an application which supports ODF. Java is only a technology > used by this application (not even for ODF-related functionality). > Neither of those is part of the standard in any way. Understood, you're talking about the OASIS guys, not the ODF programmers at Sun. > >>>>> <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". ;) > >> Oh. Should I have said "Ist hier etwa Weibsvolk anwesend?" to show I > >> understood it? :) > > Bärte, schöne Bärte! > > Und Steine! Ich hätte gern zwei Flache, zwei Spitze und 'ne Tüte Kies. > > Far too much work, and since there are JDBC drivers it may be a better > > idea to improve these drivers than writing new ones. Btw., is there a > > list of features a JDBC driver needs to offer for working flawlessly > > with OO.o? > > What is "flawless"? Just halfway kidding, and trying to get out of this > without admitting there isn't ... > > No, there isn't, and as experience told (I remember DBs such as IBM > Universe and such), there's always some implicit assumptions made in > Base's code components which we didn't know about before, and which are > not fulfilled by some exotic driver/DB. If possible, we try to relax the > assumptions in Base ... So that depends, okay. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
