Binary incompatibility issue in JuK saved data

[Jaroslaw Staniek]

Will Stephenson said the following, On 2008-01-08 11:33:

> Not to put down database storage, our database support is excellent, but for 
> many uses it's using a hammer to crack a nut, and given the way people are 
> taught computing these days, some will be tempted to go for what they know 

Of course I like JuK very much; just let me correct a few misconceptions.

> and use a database where a simple binary format is good enough and performs 
> better than loading a database library 

not if we assume that the library is most likely already loaded into the memory...

 > and a db file and initialising the database and doing a query.

The initialization of this hammer is as simple as calling open(2) and overhead 
is equal to writing 30 bytes or so, all handled at a filesystem level==) Next 
time you have to read the file, you don't have to load it entirely into the 
memory in advance.

What I say is similar to opting for UTF-8 text files instead of keeping dozens 
of CP/ISO encodings with all these various converters and autodetection routines.

Common storage format at certain level encourages data and schema sharing, 
while custom formats require developing common-intermediate format or protocol 
or API+data structures anyway.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)