Re: Goal #6 : Rating - 326561 Test/Review/Comment

["John Stowers" <john stowers lists gmail com>]

> I know that I'm a bit late, but I've been real hard pressed with studies...
>
> If the major problem is the database change, then I think that the
> time should be taken to reconsider the other database problems, and to
> make a revised database forward- compatible with future versions.
> Might I propose this:
>
> A new database format that contains the needed fields for the Rating
> patch, and also a few as-yet unneeded fields. I figure that four ints,
> four varchars, and two text fields should get us past the next four or
> five database change requirements that future patches may need. Is
> there any downside to having these new redundant, as-yet unused
> fields?

I dont think that this approach is solving the problem, nor is it
planning intelligently for the future. While the approach may work, I
think that moving feature X as field Y into the database *each time*
something new is added is not very clean.

One day, hopefully not toooooo far in future, I see f-spot using
something like Tracker [1] as its database. For the moment however
this is an implementation detail (understatement :-) ). What can be
learnt from Tracker (and by extension the freedesktop metadata
spec[2]/Exif/XMP) is the kind of information that can/should be stored
to represent a photo.

In general things go into the f-spot database to make it easy to
search and organise the photos. Theoretically we could push a lot of
the information we currently store in the DB (tags, rating, roll ID,
etc) as XMP fields in the photos but this is prohibitively slow.

> But, we also still have the Rating patch to review.
> http://bugzilla.gnome.org/show_bug.cgi?id=326561
>
> The reason we did not accept it as it was was for two reasons (mainly one)
> 1) This patch do change the database format....

I raised the discussion on that bug [3] because yes it changes the
database format, but more specifically how it increases the coupling
between the DB and f-spot arbitrarily.

I suppose in summary I would rather we sorted out some sort of DB
abstraction where photos are treated as such, and where it would be
easy to swap out the DB implementation with something like tracker in
future.

Taking this to the extreme, is there any reason (resource usage aside)
why we cant store all 20 odd EXIF/XMP fields in the database for each
photo, periodically reading/writing them back out as EXIF/XMP fields
to the file in a background thread. Obviously there would be the
existing fields like path, filename, id, version, etc.

I contend that everything (for 99% of users) users would want to do
with regard to organizing/searching for photos could be covered by
these 20 fields and *everything else is best served as a tag upon that
photo*.

So we would have

--- DB Abstraction Layer ----
GetAllTags
GetTagsForPhoto
GetPhotoMetaData
SetPhotoMeta
GetPhotoThumbnail
.. etc ...
--- DB ---------------------------
create table photos (id, path, version, .... 20 odd freedesktop fields)
create table tags (id, name, icon)
create table photo_tags (photo_id, tag_id)
create table photo_versions (photo_id, version_id, name)

Anyway sorry if this has been a bit of a rambling email, it has in
some part been spurred on by the discussion (some might say argument)
on d-d-l about getting Tracker into gnome [4] and what future fun
[5][6][7] might be possible if that is the case.

Thoughts?

John

[1] http://www.gnome.org/~jamiemcc/tracker/
[2] http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadata_2dspec
[3] http://bugzilla.gnome.org/show_bug.cgi?id=326561#c43
[4] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00175.html
[5] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00234.html
[6] http://mail.gnome.org/archives/tracker-list/2006-October/msg00183.html
[7] http://mail.gnome.org/archives/desktop-devel-list/2006-October/msg00214.html