Re: Gnome Journal Article and General Beagle Publicity
- From: Ken VanDine <ken vandine org>
- To: D Bera <dbera web gmail com>
- Cc: Kevin Kubasik <kevin kubasik net>, dashboard-hackers <dashboard-hackers gnome org>
- Subject: Re: Gnome Journal Article and General Beagle Publicity
- Date: Sun, 12 Nov 2006 21:05:06 -0500
I do think it is ready for plug and play. In Foresight, we have it
setup to run automatically. The user doesn't have to do anything. We
do also keep it very current, we always get new versions cooked up the
same day beagle releases. It has really worked pretty well for most
people for some time now. Most folks don't even understand beagle.
They just know they pop open that search tool or type in some text in
the deskbar applet and it does the right thing. The user doesn't really
know it is beagle doing the work. They have have a great search tool.
That is the way it should be, imho.
--Ken
On Sun, 2006-11-12 at 20:59 -0500, D Bera wrote:
> Hi
>
> > beagle in Foresight for well over a year now. The great news is for
> > > quite a while now there haven't been any users asking "What is this
> > > beagled thing and why does it use all my memory?".
>
> Only if you dont do the rounds of distro bugzilla and newbie forums.
> Those places are full of beagle eating CPU and memory problems (some
> of them are due to some old buggy version of beagle that hasnt been
> updated in the distros). I dont think beagle is newbie ready i.e.
> plug-and-play yet.
>
> > Especially with the most recent release, and the upcoming changes, which
> > is why I think its worth talking about. Using some of the practice
> > mentioned here:
> > http://beagle-project.org/Thunderbird
> > I run beagle (with the thunderbird backend and about 10.000 mails) at
> > about 45 MB resident for the master process and
> > Debug: Helper Size: VmRSS=34.2 MB, size=3.55, 63.7
> > its not perfect, but its certainly far more passive then before, and
> > without the tbird backend, its significantly better.
>
> Kevin, I had a brief glance at the thunderbird backend. I didnt see
> any obvious place which takes a lot of memory. If the concern is the
> ReadToEnd() in the mork parser, then you can try to replace the huge
> content string with a StreamAsArray type implementation. I replaced
> one ReadToEnd() in the html filter in a similar way, check
> Filters/HtmlAgilityPack/HtmlDocument.cs - it contains the
> implementation. Might be useful.
>
> - dBera
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]