shared wasabi implementation

[Mikkel Kamstrup Erlandsen]

2007/2/20, Joe Shaw <joeshaw at novell.com>:
>
> Hi,
>
> On Sun, 2007-02-18 at 21:15 +0100, Mikkel Kamstrup Erlandsen wrote:
> > Ok. If we are to standardize something like this, I would assume that
> > we use dbus for rpc - as far as I can tell that doesn't seem to be a
> > problem..?
>
> Yeah, Beagle doesn't use D-Bus at all right now, so to implement the
> spec we'll have to add support for it.  (We used it 2+ years ago but it
> didn't work out very well at the time.)
>
> > Fx a dbus api like:
> >
> >  - AddFile (in as metadata, in s input_file)
> >  - AddText (in as metadata, in s text)
> >
> > where the metadata argument contains things such as uri, mime, and hit
> > type (in some specified order (and maybe some
> > filtering/stemming/whatnot info)). The AddFile method sorta replaces
> > the "drop-in-special-dir" approach - the drop-in-special-dir method
> > could still be allowed for apps not talking dbus. The AddText method
> > should encapsulate the functionality of Beagles' current
> > IndexServiceRequest/Indexable duo.
>
> Thinking ahead a bit on this one, you might want to make it so that you
> can add additional metadata to an existing entry in the index.  Beagle
> doesn't support this yet, but we're moving in that direction.


I think I mentioned "getters and setters" for metadata somewhere in this
thread, but that's not entirely obvious from the context of the mail you
reply to :-) The methods I suggested was only for ingesting in the index. Or
are you saying that there should also be a way to set metadata on the
indexer and not only via the metadata api?


> By a data source you mean something that uses IndexServiceRequests and
> > Indexables?
>
> No, I mean a backend that is built as a module for Beagle.  File system,
> Evolution Data Server, gaim logs, etc.  These do produce Indexable
> objects, but they're entirely within the running Beagle instance.
>
> > In many cases the "daemon" would be the browser or a mail client -
> > which keeps a lot of state anyway, so I don't see that as a big
> > problem. In fx. an email client you can be pretty confident that other
> > apps doesn't mess with your data while you are not running, so there
> > is no need to "watch" the mailbox.
>
> I think it's the wrong approach to assume that any application will be
> running at a given time, and that to index its information that
> application has to be running.  Mail clients in particular, because
> there is so much information hidden underneath there that you might
> never see if you're only indexing email messages as the user views them.
> (I have over 179,000 unread emails, for example; I might -- and often do
> -- want to search them.)


The mailbox was mainly meant as an example, but let's stick to it anyway.
What I meant to say was that you can index the mailbox at any time, but the
is no need to keep a watch out for changes since the only app that is ever
going to change it is (say) Evolution. In a metadata aware desktop Evolution
would be emitting signals (or whatever) when the mailbox changes (perhaps
with hints as to what changed).


Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070221/34366b23/attachment.htm