[KPhotoAlbum] Optimization of index.xml

[Robert L Krawitz]

   From: "Jesper K. Pedersen" <blackie at blackie.dk>
   Date: Sun, 27 Aug 2006 21:53:28 -0400

   On Sunday 27 August 2006 21:47, Robert L Krawitz wrote:
   |    From: "Jesper K. Pedersen" <blackie at blackie.dk>
   |    Date: Sun, 27 Aug 2006 20:43:32 -0400

   |    Here is a few random thought:
   |    - if it really would change speed, then I would be rater interestd
   |
   |    - My long term goal is to get away from the index.xml and rather
   |    use a database (no no, breath again, please, and read the rest of
   |    the sentence :) this database should be something which does not
   |    require any installation, like sqlite. In addition there would be
   |    an option to export the db from the index.xml format on exit, and
   |    an option to import from this file, so that people would still have
   |    this safetynet. The reason for this move would be to free resource
   |    from maintaining two backends.
   |
   | Actually, I have nothing really against a database back end per se,
   | other than the fact that it seems like overkill.  My intuition may not
   | be correct, however.  Certainly a flat file is very expensive if
   | you're typically doing only a few updates, and that may be a very
   | common way of doing things.

   Well there are two issues.

   1) loading everything into memory is bad when you have a big DB -
   heck someone sent me an index.xml file the other day that I could
   not open on my laptop with 500 Mb of ram.

Yup, good point.

   2) loading everything into memory means that only one person can
   access the db at a time. Therefore you and your wife (or you and
   your coworkers) can't annotate images at the same time.

I've never really understood this issue up until now, but I can see
the possibilities, particularly in a client/server environment.  In
particular, I could see a web service built around this.  For example,
my wife might want to access photos on her Mac while I'm accessing
them on my laptop, while they're actually stored on my server, and
we're both doing it through our web browsers.  I could also use the
database to serve images for organizations I belong to, with
appropriate password protection, and a professional photographer might
be able to use this to sell photos on the web.  Think in terms of a
wedding photographer who makes the shoot for each wedding available to
the client.

This is a long way off, but I think I can see real possibilities for a
database back end.

   |    - the compressed index.xml option in the settings menu does
   |    actually only save index for each image, did you try that?
   |
   | Given the history of the compressed option, no.  If the
   | compressed index.xml isn't simply a zip or gzip or bzip2 of the
   | index.xml file (and it apparently isn't, given what you say here
   | and what other people have reported), I'm not touching it with a
   | ten foot pole.  Anything that increases the number of code paths
   | through the save code is asking for trouble.

   OK, here is a very good reason for using this if you think that
   way: *I* am using the compressed option.

OK :-)

   Basically what it does is that it saves a more unreadable index.xml
   (indexes vs. the real names). This index.xml is approx twice as
   fast loading as the full index.xml.

Ah, that's exactly what I was suggesting beyond the "easy" stuff.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton