J5’s Blog

Lately people have been getting excited over the prospects that freedesktop.org has to offer. This is cool and certantly fd.o has contributed significantly to unifying some of the desktop plumbing behind a couple of standards. HAL, D-Bus, Cairo and others have proven themselves useful in their own rights which has caused many to see fd.o with stars in their eyes. Reality check; fd.o is not the holy grail that will save us from ourselves. Touching it does not automaticly bless a project. Hosting a project off of fd.o does not mean it is accepted by all concerned nor does it mean the specification for that project all of a sudden becomes a defacto standard. Fd.o was concived specificly NOT to be a slow working standards group formed of committees that put out specs that were relevant years ago but somehow seem outdated and over engineered when they are released. Fd.o IS A proving grounds for specs and implementations that are of interest to unifying the many different Linux desktop platforms with some common infrastructure. Projects still have to make it on their own merit. If a specification becomes a standard it is because all or most of the interested parties have agreed to use it and not because it is hosted on fd.o.

Why do I write this? Because I see people blindly rushing to fd.o as the new fad platform. Fd.o is very important resource to the community and as such there needs to be a realistic view of what it is and what it isn’t. From my experience in the past trying to make a totaly generic platform has caused many problems. My first few FOSS projects failed to gain any traction because I wanted to make them desktop neutral and did not want to use the powerful features that focusing on a specific platform would give me. Even when I briefly worked on GAIM there was a huge culture of not wanting to integrate with GNOME so that it could be acceptable for KDE users to use. Sometime being desktop agnostic works really, really well and the benifits of having everyone work together on one piece of technology to solve a problem overcomes the loss of dirversity that multiple competing projects would generate. On the other hand approaching a new problem from only one direction can cause stagnation and lowest common denominator syndrome. One needs to decide whether a better user experience (and faster development) can be gained by targeting a specific platform or if making a project agnostic to the platform is the optimal choice. Rushing to fd.o with every new project without first exploring its merits and feasability of adoption by diverse groups devalues the worth that fd.o has built up over the short term it has been in existance. I’m not saying any project on fd.o fits that description right now but the hype I see surrounding it (a victim of its own success) makes me feel that the above is inevitable. It is the whole signal to noise ratio debate that happens on the mailing lists and I would hope that such a valuable resource does not fall victim to the same fate.

–
J5

The time has come to clean up the
Python D-Bus bindings. Ray Strode and I sat down today and discussed
where we would like to see the bindings go. Right now they are
starting grow some bit rot having been one of the first useful
bindings to come out for D-Bus. Some of the things discussed was
starting from the premise of creating simple clean bindings that fit
into the Python way of doing things. This means stripping away a lot
of the low level D-Bus API-isms and concentrating on the higher level
interface being easy and intuitive to use for the core functionality
of D-Bus which is creating and using IPC services. Where low level
functionality is needed we will need to find a way to fit it into the
higher level API.

What does this mean for the end user?
The API is changing and I won’t hesitate to break backwards
compatibility. Hopefully the API will be changing for the better and
this will be the final API for 1.0. Below is a rough outline of
what I want to implement and how the API’s will be changing. Any
constructive input would be greatly appreciated.

• Introspection

  • Invoking Methods (reading
    introspection data from a service)

    • Use introspection data to
      construct proxy objects on object creation (i.e.
      RemoteService.get_object())

      • use parameter signatures to
        marshal objects

    • do not block for introspection
      data

      • When blocking methods are
        called, block until introspection data is received then call
        blocking method

      • Async methods are queued and
        called when introspection completes

      • On failure to obtain
        introspection data (timeout, object does not support
        org.freedesktop.DBus.Introspectable, etc.) pending methods are
        executed using the old way

  • Exporting Introspection Data

    • every registered object gains
      the org.freedesktop.DBus.Introspectable interface

    • use inspect.getargspec() on list
      of exported methods to get the parameter count

      • all parameters will be exported
        as varients

        • Should we provide a way to add
          hints so that we can do type checking or make it easier to use
          from C? My gut says no but perhaps add this if some sort of
          static type checking enters python.

  • proposed standard annotation to
    the introspection format

    • org.freedesktop.DBus.Doc for
      document strings. It is easy enough for us to get from Python
      (method.__doc__) and allows users of the python bindings to call
      __doc__ on a proxy object’s methods and get documentation

  • registering signals

    • Signals should be registered
      with dbus.Object so that they can be exported in the introspection
      data.

    • Parameter format needs to be
      passed when registering

• Method calls

  • methods are called with their
    arguments listed first and may contain a number of optional
    keywords

    • method(arg1, arg2, …,
      callback=None, error_callback=None, interface=None)

      • callback keyword

        • when set to None method is
          blocking

          • catch errors using try/except
            blocks

        • when set to a python function
          or method callback is called when the pending call returns

          • callback signature depend on
            the number of arguments sent in the return method.

            • there are no extra
              parameters sent into a callback.

            • to construct a callback that
              has a variable number of return values use the *args construct
              (in general you should not use this too much)

      • error_callback keyword

        • callback signature is def
          error_cb(exception): where exception is a python exception
          generated from the D-Bus error

        • for async calls if this is set
          to a function or method it will be called on any D-Bus error

        • For blocking calls this will
          throw an error if set

      • interface keyword

        • using this one can override
          the default interface and call a method on another interface

• Signals

  • Signal callbacks will be dropping
    the Sender object

    • sender just exposes API details
      like the message and signal name

  • signal callbacks will look
    exactly like async method callbacks

    • do we need an signal_error
      callback also?

• Interfaces

  • objects initialized with an
    interface will consider that interface the default interface

    • object =
      service.get_object("/org/designfu/SomeObject",
      "org.designfu.SampleInterface")

      • org.designfu.SampleInterface
        becomes the default interface

  • methods can override the default
    interface

    • object.Introspect(interface=â€?org.freedesktop.DBus.Introspectableâ€?)

  • the Interface wrapper object acts
    just like an object but casts the wrapped object to another
    interface for all methods

    • introspect_interface =
      Interface(object, “org.freedesktop.DBus.Introspectable�)

    • introspect_interface.Introspect()

  • when constructing the proxy
    object methods are all name spaced in a dictionary by their
    interface from the introspected data

    • proxy_dict =
      {“org.freedesktop.DBus.Introspectable.Introspect�,
      self.__generated_bindings_introspect,
      “org.designfu.SampleServiceInterface.HelloWorld�,
      self.HelloWorld}

• What is going to go

  • Messages, PendingCalls, Iters,
    etc. will no longer be exposed to the user (or at least moved into
    the low level bindings with warning that anyone using them will be
    flamed)

  • Nomenclature (such as service)
    will change to reflect the current naming in the D-Bus spec

  • The low level bindings will be
    stripped of methods not used by the higher level bindings.

Just recived this comment in redhat bugzilla today in response to a sound-juicer bug I fixed:

J5… you are a god amongst men, it works as it’s supposed to, preferences and extracting..

While it is a bit over the top I have to admit it does stroke the ego. And this all came from moving one line of initilization code up above another line of code. While I was manning the Gnome booth at Linux world there were a couple of people who came up and just said “thank you” and walked away. If I managed to query them further the usualy response was, “Just thanks for all the great work Gnome does. I just wanted to say thanks.” While these shows of positive feedback may be few and far between, one of these can wipe away all the negitive feedback one might get in the course of working on an FOSS project. So for the most part I think the community “gets it” but the ones who don’t are often the most vocal.

Ok, so I mailed out to a bunch of people about my party this coming Saturday at my new apartment in Porter Square. I may have missed a few so here are some of the details. If you know me and live in the Boston area drop me a line and I will fill you in on where the party is.

Bar Stocking Party Saturday April 9th @ 8:00pm

As many of you may or may not know Colin Walters and I have recently become roommates and moved into a great apartment in Porter Square. To celebrate we are throwing a Bar Stocking Party at the apartment this Saturday, April 9th. Feel free to bring friends.

What is a Bar Stocking Party?

The simple answer is a party where everyone brings their favorite hard alcohol. Whatever is left over at the end of the night stays for the next party. The idea is to bring the ingredients needed for your favorite drink and share the mix with others. I will supply some soda, limes, lemons, ice, drink making equipment and snacks. I don’t want people spending too much money so if the ingredients get expensive feel free to plan with a couple of people.

Rules of a Bar Stocking Party.

* No beer – sorry beer lovers but this is a hard alcohol only event. If this party goes well I might throw an Oktoberfest party where everyone brings a sixpack of some exotic beer.

* Know how much you can drink – This is hard alcohol. We have plenty of floor space to crash on (bring a sleeping bag if you think you will need to crash) and we have nice access to the T. So car pool or take public transportation if you think you are going to drink a lot. The last T train is somewhere around midnight and the first train on Sunday is around 6:00am. Breakfast will be served to those who can make it till the morning.

* Make it fun – sure the standard rum and coke is always good but if you know of some exotic drink mix go with that. Also no drinking game will be stopped or otherwise interrupted (except if they block access to the alcohol). Bring your favorite.

Didn’t you know D is the new G (or K for KDE folk). In honor of the new naming fiasco I have decided to change my nick to D5 for awhile. When the next naming fad roles around let me know. Hey, there are only 26 letters in the english alphabet so we need to conserve. D is now the officaly sanctioned letter of the month. Anyone deviating will be flogged in public. So be cool and place a D- in front of your nick today.

–
D5