Re: Best way of using Beagle to index data CDs

Hi Nikolai,

> Please direct me to the right mailing list if this isn't the
> appropriate one for things like this.  There doesn't seem to be a
> dashboard-users mailing list.

This is the right place. Welcome aboard.

> I would like to use Beagle to index my data CDs.  I figured that
> static indexes was the way to go, but I haven't quite determined the
> best way of doing it.  My initial idea was to create an index for each
> CD, so that I could simply remove the index associated with a CD if I
> threw out the CD.  But then I started worrying about using hundreds of
> static indexes.  My idea then was to merge the static indexes into a
> master index that I could rebuild whenever an index was added or
> removed, using $(beagle-manage-index merge).
> Does this make sense?  Does anyone have a better suggestion?
> Also, I figured that I wanted to add an attribute to each file indexed
> in this way that says what CD it is on, for example, 'disc:N', where N
> is an integer.  There doesn't seem to be a way of doing this yet with
> beagle-build-index.  Is this something that would be interesting to
> see as a patch, or are user-defined attributes outside the scope of
> Beagle?

You are more or less in the right track. As Kevin pointed out, one way
it so leverage static-indexes. Due to the way static indexes work, it
isnt directly possible to use that for removable index. There is a
"--tag" option to static indexes, which can be used to tag files when
using beagle-build-index. You can use that to identify files from each
medium. If you merge several indexes, there would be two kinds of
1) Files that are not in the filesystem would not be reported (happens
for any static index)
2) If there are files in different removable media but with same
absolute path, then only one of them will be returned. And there might
be more weirdness.

There are several layers of complexity in handling removable medium -
some due to medium discovery. I started implementing a two part
approach which includes a backend to handle "removable-indexes" and a
build-removable-index tool to create/update such indexes.

I abandoned the effort because there are some design changes that I
think it should have.
If you/anyone wants to work on this, I can explain my ideas in detail.

- dBera

Debajyoti Bera @
beagle / KDE fan
Mandriva / Inspiron-1100 user

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]