Weekly report

Hello All,
Sorry for the delayed report ... my horoscope didn't mention that
sudden travel would turn up in my near future. :-)

Coding is going well. I got stuck on a couple of problems but thanks
to help from Alp Toker and Joe, I am on my way again.

* I had a bug in my code that uses managed DBus -- when implementing a
DBus interface using a C# interface, all the methods/events _must_ be
part of the interface definition. Yes, it was a bit silly in

* As pointed out in an earlier thread, when using the BeagleClient API
in async mode, you need a GLib main-loop running, or you won't see any
of the events that should be triggered.

* It turns out that in order to simplify clients (and bindings), both
"session" and "search" objects are not DBus objects. These are
addressed by a string handles instead. This means that the server
(that's us) has to manage objects ourselves. Slightly unclean for

* Finally, the NewSearch() method causes a search to start
immediately. This might cause a race, where (for example) a HitsAdded
event might be raised even before the NewSearch() returns (the client
would be confused, since it gets hits on a search handle that it has
not yet seen). While this is easy enough to handle on our side with a
lock, it might be nice to just add a new StartSearch() method to
Xesam. Of course, this would mean one more DBus call, which is not
desirable either -- I will talk to Mikkel (who is coordinating the
Xesam effort) about this.

So the plan for next week is to:
1) Continue implementing the Xesam interface (HitsSubtracted, GetHits etc.)
2) Start implementing each of the features supported as Session
properties (selection of fields to return, blocking vs. live searches,
3) Figure out whether it's better to do locking from our side on
search objects, or push that into Xesam (probably the former).

Arun Raghavan
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com

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