Re: Thunderbird support

Thanks for the feedback Joe!

Joe Shaw wrote:
> Hi Johann,
> (1) It would only work while Thunderbird was running.  Ideally you'd
> like to have your emails indexed even if you're not running the mail
> program.
That is true but not really a problem if the emails to be indexed
could somehow be queued for indexing. So once the initial indexing
of emails already present is done (see below), new emails are
indexed only when/after TB is run, but unless it is run, there
wont be any new emails anyways :)

> (2) Scheduling how you index the mails would be tricky from inside TB.
> One option is to only index emails when you view them (similar to how
> the Firefox extension works).  This sucks because you only index a
> mail when you view it in TB, and personally I have thousands of
> messages -- some of which I never even read -- which I might want to
> search later. 
> The other option is to gradually walk the list of mails
> and send them to Beagle for indexing.  You'd want to code this in TB
> so that it didn't (a) use all CPU and (b) save tons of temporary data
> to disk, and that's tricky.
I think there should be an on-demand option to index existing folders
or folder hierarchies in order to once-off index all you already have.
Incremental indexing of new messages would then be done when one
views the message - this could set a flag in order to mark the message
as submitted for indexing.
Finally, a delete or move operation would have to schedule a
re-indexing in order to keep the index up-to date.
(this is one of the things that are probably extremely hard to
do when directly accessing files).

One big plus of this approach would be that spam would never be
indexed unless a user actively looks at spam emails, but the plugin
could ensure that it is removed from the index when a) marked as
Junk or b) deleted. Or, the user could temporarily switch off the
plugin when browsing through spam for some unknown reason.

> (3) Keeping state is tricky.  Especially if you go with the
> crawling/scheduling path in (2).  You'll have to save some state about
> what messages have been indexed, which have changed, etc.
I think when large folders are submitted for indexing manually on
demand, and otherwise only viewed emails are scheduled unless
already done, this would not be hard to solve.

> So it's a tough problem; (1) is insurmountable with a plugin, (2) and
> (3) are doable, though.  Whether (2) and (3) are harder than writing a
> sane Mork parser, that's definitely up in the air. ;)
Well I have looked at Mork a little while ago and can hardly imagine
anything that is harder than a parser for that :)

>> Finally, if the plugin is installed it could also become more easy
>> to show an email from a beagle search result list.
> I'm not sure I understand what you mean by this.  Can you give a
> little more detail?
What I meant is that somehow, TB would have to display a message that
is clicked in the resultlist of a search. I thought that when there
is a plugin, it might be easier to communicate which message to show,
but maybe this works just as well without a plugin (I have really
no idea how to uniquely identify a message within TB).


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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