Re: Opera backend for Beagle

["Kevin Kubasik" <kevin kubasik net>]

Hmm.... well, so far, there hasn't been much in terms of issues. As a
general rule, the backend is behaving nicely. I have a few commits
that I will probably make tonight if the continue to go well, however,
I do have a design question.

The backend basically works not unlike the old gaim backend. On
startup it loads a history file (actually an index of on-disk cache
elements, but close enough) and stores a in-memory representation of
it, this is generally a fast and light operation. Then, we get an
enumerator of all the cachefiles mentioned and their source, and
proceed to index the content (this part is throttled by the daemon).

The question is, is it ok to do the history file reading like this, or
should I break that up? Along the same line, once I have the
enumerator for the history file, should I dispose of the object
representation (on inotify events we reconstruct/reload it).

On 11/1/07, Debajyoti Bera <dbera web gmail com> wrote:
> > 2) Parses history file in one go, then throttles the indexing of
> > history items. However, it is possible, if a user changed the opera
> > config to something like 5,000,000 items or something, we would be
> > sitting with all that in memory.
> >
> > If we have a defined time for 0.3.0, I could target the cleanup of #2
> > before then. I'll keep watching for other bugs, but against the Opera
> > 9.0 series it seems pretty stable/awesome.
>
> Ok - go ahead. More than #2, keep using it for a few days, you might notice
> something.
> I was planning to roll out a test tarball sometime early next week. So if you
> could do something before that, it would be nice. If not, its not a big deal,
> changes can be made till we roll out the final tarball.
>
> --
> -----------------------------------------------------
> Debajyoti Bera @ http://dtecht.blogspot.com
> beagle / KDE fan
> Mandriva / Inspiron-1100 user
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog