Re: Best way of using Beagle to index data CDs

["Nikolai Weibull" <now bitwi se>]

On 10/17/07, D Bera <dbera web gmail com> wrote:
> 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
> problems:
> 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.

OK.  Both of these are real problem.

Problem 2 can be solved by making sure that one uses --remap correctly
to make each prefix unique, for example, "/media/<disc id>/".

Problem 1 is a complete bummer.  That makes beagle more or less
unusable to this end.  How do we solve this?

It seems that you've basically solved both of these problems in
BuildRemovableIndex.cs by introducing a new URI protocol (removable)
for solving problem 1 and using media_name for solving problem 2.

However, BuildRemovableIndex.cs hasn't been completed.  It doesn't
seem to be missing that much, though.

How would one tell Beagle to report any removable:///* URI?

I guess I'm not familiar enough with the structure of Beagle to know
where to begin resolving these issues.