Midgard and D-BUS

1. Piotr Pokora

   Midgard and D-BUS

   Thu March 27 2008 09:40:04 UTC
   Hi!
   
   One of the planned Midgard's feature is D-Bus support:
   <http://www.freedesktop.org/wiki/Software/dbus>
   And it seems that it's worth to implement it before other major features
   like new Midgard Style Engine.
   If things go well we can implement it in Midgard 2.0 and 1.9.
   
   # D-Bus messages
   
   Basicaly we can use two kind of messages with D-Bus:
   
   * signals
   * data proxies
   
   The first one behave like typical events. Application just triggers some
   signal and listener is invoking its callback for it.
   The second is much more complicated and allows to pass data ( like
   objects ) through D-Bus. So PHP objects could be passed to python
   application and so on.
   
   But first of all I would like to focus on first solution, as specific
   PHP+Apache environment is full of surprises.
   
   # D-Bus servers
   
   By default D-Bus comes with two servers, global and session one. There
   is possibility to create own server, but do we need own server
   implementation? Session one might be quite difficult to use so I think
   if global one should be enough. At least for a good start.
   
   # Midgard paths
   
   This is quite obvious that we will use `/org/midgardproject` path,
   however we need more to make clear distinctions:
   
   * Connection and configuration
   * MgdSchema classes
   * Core classes with databases access ( midgard_dbobject : sitegroup, user )
   * Core classes
   
   And used path could look like this:
   
   `/org/midgardproject/CONFIGURATION/mgdschema/midgard_article/GUID/METHOD_NAME`
   
   or without explicit "feature" identifier
   
   `/org/midgardproject/CONFIGURATION/midgard_replicator/export/GUID`
   
   # Issues
   
   An example above allows to pass configuration name in message's path. So
   for example an application which acts as listener ( daemon ) should be
   able to establish connection using given configuration name even if it's
   been already done for different configuration. But problem might be
   impossible to solve in Midgard 1.9 as connection handling is still the
   one implemented for Midgard 1.4.
   
   Solution could be to implement multiple connections in Midgard 2.0 and
   than "port" kind of API to midgard-php only.
   Or ( the better one I think ) run as many PHP daemons as many Midgard
   configurations found.
   
   # Implementation
   
   Midgard grows up every year and I would like to avoid overloaded (
   default ones ) dependencies. That's why I have been thinking about
   implementing plugins for Midgard. D-Bus would be just Midgard plugin
   which could be compiled optionally. This is of course against our simple
   `configure && make` rule , but beginners would avoid too much problems
   when installing Midgard for the first time. Distro packages should of
   course support all available plugins.
   
   
   D-Bus support is really nice to have. And a must for a future. It seems
   to be simple, however the more traps we can find now the better for
   stable implementation.
   
   Ideas very welcome :)
   
   Piotras
   _______________________________________________
   dev mailing list
   dev@lists.midgard-project.org
   http://lists.midgard-project.org/mailman/listinfo/dev
   •  Reply
   •  Report abuse
2. Piotr Pokora

   Re: Midgard and D-BUS

   Thu April 03 2008 13:21:07 UTC

   Hi!

   I wrote proof of concept simple API in Python for midgard_dbus. Basically, the approach is to notify others and send simple data. String in our case.

   Implemenation hides 'org.midgardproject' name so everyone writing code on higher levels must only focus on paths which are identified by simple objects.

   On PHP level code should look like this:

   $article_service = new midgard_dbus("/midgard_article");
   $replicator_exporter = new midgard_dbus("/midgard_replicator_exporter");
   

   The path passed to constructor is freely definable and it's much more of convention than of API rules.

   Every created object have notified signal which is emitted when object got signal from D-Bus. So we pass signal and simple data and let language's callback do the rest.

   On client side we have simple method:

   $midgard_dbus::send("/midgard_replicator", $data);
   

   Which find D-Bus object with '/midgard_replicator' name and pass it given data. Data is string so we can send guids, own messages, file locations or even serialized objects.

   Both servie and client side always work in connection context, so it's impossible to change connection. For multiple connections we need multiple services.

   What do you think?

   Piotras

   •  Reply
   •  Report abuse