GTG GSoC week 7 =?UTF-8?Q?=E2=80=94?= Client/Server Separation

Hi all,

  My report for week 7 is at . The
version below lacks links...

Recently I have been working on two things related to achieving a
client-server separation in Getting Things GNOME!

One is a test suite that will cover all aspects and functionality of the
DBus interfaces. The second is low-level code to support the interfaces

Why not do them in sequence? Well, tinkering with the low level code is
helping to outline what will and will not be possible with the
"DBus magic" I've blogged about on two previous occasions. Tests don't
have to target against code that already exists, but they should at
least target code that could exist.

To explain more, the concept is to have more than just a DBus interface
on the server. For the client, the dbus-python ProxyObject and Interface
classes are a useful starting point, but I want to go further and let
GTG! clients behave as if the objects they are handling were local
(although, as James pointed out, clients will be faster if they don't
naïvely trigger too many calls on the bus). This means providing a
client library that clients can optionally import and use, instead of
grappling directly with the server's DBus interface.

In coding this client library several interesting winkles have come up.
For example, the DBus tutorial discusses the distinction between
well-known names ('org.gnome.GTG') and unique names (:34-907)—but these
are only for buses. Each object (e.g. a GTG! Tag or Task) available on a
bus needs to have an object path ('/org/gnome/GTG/Task/12345' or

Because of the DBus message-passing architecture, there is no way to
know if anything exists at a given object path, until you try to access
it. By analogy, the Internet's Domain Name System (DNS) can tell you
that my website exists at such-and-such an IP. But
to determine if there is anything at a specific URL
(, you need to try to access it and
maybe get an HTTP .

Clients only care about actual Tasks and Tags, and repeatedly checking
that its proxies still reference valid targets would be a pain in the
neck. The solution is to provide helper code that checks the remote
object exists before it hands a proxy to the client.

Another problem that is cropping up is that the client needs to be able
to understand and manipulate the tree hierarchy of Tags and Tasks, over
the bus. But that will be another post...

Paul Kishimoto
SM candidate (2012), Technology & Policy Program
Massachusetts Institute of Technology — +19053029315

Paul Kishimoto
SM candidate (2012), Technology & Policy Program
MIT Engineering Systems Division  (ESD/TPP) — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part

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