Beagle 0.0.5

I'm pleased to announce the release of Beagle 0.0.5.


To download the 0.0.5 tarball, visit the Beagle web page at

There is lots of useful information about compiling and using Beagle on the

If you are running SuSE or the Novell Linux Desktop, we have an open carpet
server with snapshots and packages for all of the dependencies:

Joe Gasiorek writes a regular Beagle newsletter.  You can read it at:

Nat Friedman made some cool movies that demonstrate Beagle in action:

The latest gossip is available at:

We still talk about Beagle on the dashboard-hackers mailing list:

Osmium is the densest element:


Beagle is a tool for indexing and searching your data.  It is in an early
stage of development and should be considered experimental.  Beagle is
improving rapidly on many fronts, but it is not yet stable enough for
full-time, everyday use.

The Beagle daemon transparently monitors your data and updates the index
to reflect any changes.  So for example,

* Files are immediately indexed when they are created, are re-indexed
  when they are modified, and are dropped from the index upon
* E-mails are indexed upon arrival.
* IM conversations are indexed as you chat, a line at a time.

Beagle uses the Lucene indexing system from the prodigious Doug

Best is a graphical tool for searching the index that the daemon creates.
Best doesn't query the index directly; it passes the search terms to the 
daemon and the daemon sends any matches back to Best.  Best then renders the
results and allows you to perform useful actions on the matching objects.

Indexing your data requires a fair amount of computing power, but the Beagle
daemon tries to be as unobtrusive as possible.  It contains a scheduler that
works to prioritize tasks and control CPU usage, based on whether or not
you are actively using your workstation.


Beagle has many dependencies, and thus can be difficult to compile.
It requires:
* The full Mono stack, including Gtk#. (We are developing under 1.1.x,
  but 1.0.x should also work.)
* An inotify-enabled kernel
* D-BUS 0.23
* Evolution-sharp 0.6
* Gecko-sharp
* Gsf-sharp
* Gmime


* Improved interaction with Mono GC (Jon Trowbridge, Joe Shaw, Ben Maurer)
* Dot Lucene 1.4.3 (Joe)
* Snippets in Files, IM logs, and Tomboy Notes (Jon)
* Query infrastructure improvements (Jon)
* Dynamic backend loading (Fredrik Hedberg)
* Large queries are now much faster (Joe, Jon)
* Better handling of index optimize operations (Joe)
* Faster IM log parsing (Jon)
* Properly quote SQLite queries (Edward Cho, Chris Orr)
* Work around .NET Uri class weirdness (Adam Lofts)

* Liferea backend (Carl-Emil Lagerstedt)
* Launcher backend (Joe Gasiorek)
* Thunderbird backend (Fredrik)
* The Tomboy backend works again (Robert Love)

* Better infrastructure for source code filters (Veerapuram Varadhan)
* Abiword filter (Varadhan)
* Fortran filter (Vishravars)
* Pascal filter (Veerapuram Varadhan)
* PHP filter (Vishravars)
* Improved RTF filter (Varadhan)
* Improved PPT filter (Varadhan)

* IM log viewer (Lukas Lipka, Tuomas Kuosmanen)
* Right-click menu for Best (Shobith Alva)
* Document tile enhancements (Varadhan)
* Remember Best's position (Joe G.)
* Fix search entry focus problem (Stephen Solka)
* Client-side hit filtering (Nat Friedman)
* Calendar tile (Lukas)
* Fixed images under Mozilla 1.7 (Joe)
* Better addressbook look-ups (Nat)
* Use freedesktop-spec thumbnails (Fredrik) 
* IM fields in contact tile (Nat)

Everything Else:
* Build fixes (Everyone)
* Newletter (Joe G.)
* Wiki wrangling (Joe G.)
* Bold, haunting cinematic vision (Nat)
* Snapshot Resurrection (Joe)
* Inotify hacking (Robert)
* D-BUS hacking (Joe)
* GMime hacking (Joe)
* Win32 porting (Fredrik)
* All the stuff I forgot (All the people I forgot)


It doesn't take that much ingenuity to confuse the file system backend.
Certain operations are yet not fully implemented -- in particular,
the right thing doesn't happen when you move a file.

The beagle daemon seems to grow over time, using more and more memory.  This
is not actually a memory leak, but is a result of the mono runtime's heap
growing due to suboptimal allocation patterns and heap fragmentation.  We now
have a much better handle on the problem and have taken a number of steps to
start fixing it.  In particular, the rate of memory growth has been slowed.

At this point in development, we cannot commit to stable APIs or file formats.
You will almost certainly need to delete your indexes and start again at
some point in the future.

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