Re: kmailqueryable


You're making all of my points for me. :)

On Thu, 2005-08-04 at 11:10 -0400, D Bera wrote:
> Mostly true. However,
> * There will be a hure repetition of code in each queryable -
> regarding setting up inotify, crawler, etc.

Yes, but every queryable has to do this anyway.  We used to have a
general crawler class.  It turned out to not be very useful.  You have
to do this whether you have a queryable class or a crawler class.

> * Dot-folders, tmp files, hidden-files are widely used in these
> maildir stores. So, just cant handle every directory and file created
> in the same way.

Exactly, which is why when we need specialized queryables, we can add

> * Naming convention is different in different cases - and they store
> the mail-folder name in different ways.


> Conceptually, it looks to me like two separate entity - a minimal,
> simple queryable which just checks the presence of a crawler and asks
> the specific crawler (which would also be small - just informs the
> queryable what to do with a new directory/file) what to do the files
> and directories it sees. It would just look a bit cleaner and easily
> extensible.

The Queryable is the thing which generates the Indexable objects with
backend-specific properties on them and adds them to the index.  That's
work that needs to be done either way, whether it's in the queryable
class or a crawler class (I don't think it should even be a separate
class...), so it doesn't really save any code and it breaks the existing
model we have.


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