simple search api (was Re: mimetype standardisation by testsets)

[Jos van den Oever]

2006/11/28, Joe Shaw <joeshaw at novell.com>:
> On Tue, 2006-11-28 at 19:11 +0100, Mikkel Kamstrup Erlandsen wrote:
> > I think I see where the disagreement comes from. Currently the premise
> > for the simple search api has been that it didn't need any language
> > bindings. Applications would certainly wrap the interface in a native
> > object allowing for mainloop integration, but it didn't need any code
> > from the Wasabi project to work.
>
> This is somewhat contrary to the idea behind D-Bus, however.  The entire
> idea behind D-Bus is that the low-level libdbus APIs are used by
> bindings to integrate with the higher level platform.  Application
> developers operate in their language/environment of their choice.  The
> API design should keep this principle in mind.

Agreed.

> > I still think it is possible to write a responsive ui with with the
> > paging queries instead of the fully async ones. An application need
> > not request 1000 hits at a time it could send 10 queries requesting
> > the hit ranges n*100 to (n+1)*100 for n=0..9. An example of this is
> > the Tracker search tool and the Tracker deskbar plugin (actually they
> > only perform one query, but still).
>
> I'm not so concerned about the overhead in doing the queries themselves,
> although it could become somewhat prohibitive if you're querying massive
> amounts of data.  What I'm more worried about is that this is a remote
> procedure call to another application.  There's no guarantee that the
> server will ever return, let alone in a timely matter.  Your application
> might be doing the right thing with paging, but another application may
> be hammering or even DoSing the search service.

Simple method calls in DBus are not synchronous at all, even though we
call them that. A method in DBus simply means that you may expect one
reply. The GUI should always deal with a lag in a DBus call and keep
the application responsive. Even if the application never returns a
result from a DBus method call, this should not handicap the
application in any way. If it does, it's a badly/too quickly written
application.

Cheers,
Jos