Hey Lukas! On 6/1/07, Lukas Lipka <[EMAIL PROTECTED]> wrote: > So I've finally managed to successfuly complete college and graduate. > Hooray! :-)
Congratulations! What does the more distant future hold for you? > Could anyone brief me what is new in Beagle land? What is the state of the > pooch and where are we heading at the moment? I have more than 4 months free > and hope to get to do some hacking real soon. We've been working toward a 0.3.0 release, and tons of work in the core indexing has been going in to make Beagle run more happily. We've completely redone the way "child indexables" are generated and handled. Now parent items are not indexed until all of the children have been indexed. This way, if the indexing process dies for whatever reason in the middle of indexing an archive, we'll be able to more gracefully recover from this problem. Also with child indexables, we now process them entirely from within the helper process. This removes the ping-ponging we had. Before a child indexable would be generated by a filter in the helper process, it would be saved to a temporary file, sent back to the main daemon process for scheduling, when its turn came up it would be re-sent back to the helper, and then indexed. We no longer send it back to the daemon process, simply a message that we've generated them, and the scheduler can say whether or not to index them right away. It's also possible to eliminate the temporary file entirely for some items, but we're not there quite yet. We now support adding metadata from external sources; the reference implementation of this is the Nautilus metadata backend. If you use Nautilus emblems or notes, these will be indexed by Beagle and displayed in search results. I expect this is how tagging will be implemented... now we just need a good, simple, and maintained desktop tagging library. We have some preliminary support for XMP sidecar files. These actually are incredibly difficult to support, and so we have basic indexing of them, but renaming files, etc. doesn't work. Lots of improvements to the file system backend's generation of indexable objects. Just about everywhere we are now using indexable generators, which means many fewer objects are generated and scheduled, which means faster batched indexing and less memory usage. Speaking of the file backend, I feel at this point that FSQ could stand for yet-another-rewrite. I think we made some incorrect design decisions with this iteration, and we focused on trying to handle some very hard but relatively uncommon situations at the expense of handling more common desires like the ability to limit searches by path (in the daemon). We're also looking at improving the UI, and I'm trying to get Larry Ewing (of F-Spot fame) to help us here. Better result layout (ie, using blank space when there are results to fill it) and adding "advanced search" controls are among the two big things I'd like to see there. And of course, as you already know from attacking bugzilla, there are little featurelets and buglets here and there that can always use love. Glad to have you back. :) Joe _______________________________________________ Dashboard-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dashboard-hackers
