Month: January 2006

Aren’t discussions via blogs fun? 🙂

Federico: two points:

1. Using the new GObject instance private data API, rather than the private data scheme that GNOME hackers have always used, is a small optimization in itself – the private data is allocated in the same chunk as the object itself.

   As with all optimizations, you weigh up the benefit against the code obfuscation. In this case, I don’t think the GObject scheme makes the code more difficult to understand … especially since it’s likely to become as much of a second-nature idiom as the old scheme. It’s also one less opportunity to leak memory.

2. Using the GObject scheme, instance private data could have been added without the runtime hit you were seeing … even where the object structure couldn’t be extended without breaking ABI.

   To do so, you’d just go back to something similar to Owen’s initial suggestion for how the API should be used – in a static variable, you’d store the offset between the address of the object structure and the private data and use that offset for efficient access to the data. add_private() originally returned this offset, but it no longer does, so you’d need to calculate the offset in instance_init() – but it is guaranteed to be constant.

   Granted, that’s a nasty hack which would genuinely obfuscate the code … but at least it would actually be possible to add private data, whereas it wouldn’t be possible with the old scheme.

   Update: Tim points out that the offset to the private data isn’t constant across all instances – the offset will be larger for subtypes since the private data is allocated after all object data.

Yesterday I posted some code which shows how to use Fedora Directory Server’s “persistent searches” using OpenLDAP’s client library. Here’s that same code, but as a Python module.

Federico: the combination of a “*priv” field and GObject private data is the best way to go:

struct _PangoFcFont
{
   ...
   gpointer priv;
   ...
};

#define PANGO_FC_FONT_GET_PRIVATE(obj) ((PangoFcFontPrivate *) ((PangoFcFont *) obj)->priv)

static void
pango_fc_font_class_init (PangoFcFontClass *class)
{
  ...
  g_type_class_add_private (object_class, sizeof (PangoFcFontPrivate));
}

static void
pango_fc_font_init (PangoFcFont *fcfont)
{
  fcfont->priv = G_TYPE_INSTANCE_GET_PRIVATE (fcfont, PANGO_TYPE_FC_FONT, PangoFcFontPrivate)
}

Indeed, that’s why g_type_get_private() was added. You get the best of both worlds – the convenience of a priv pointer with the fact that the private data is allocated in the same chunk as the object itself, without the inefficiency of calling get_private() a lot or the extra static variable in Owen‘s original proposal.

Figuring out what the story is with LDAP notifications isn’t terribly easy. There are a number of different protocol extensions out there:

• Netscape’s Persistent Search or PSEARCH. Fedora Directory Server supports this. Extends the standard searchRequest such that it doesn’t complete immediately, and returns any changes to the matched by the search.
• Triggered Search Control or TSEARCH. Not sure what implements this. Similar to psearch.
• Microsoft LDAP Control for Directory Synchronization or DIRSYNC. Implemented by Active Directory, but requires the client to poll for changes.
• LDAP Content Synchronization Operation or SYNC. Implemented by OpenLDAP and allows both polling and persistent modes.
• LDAP Client Update Protocol (RFC 3928) or LCUP. Similar to SYNC. Not sure who actually implements this.

The strangest thing about all this is that LCUP is the only one of these that progressed from Internet Draft to RFC, yet neither OpenLDAP nor Fedora Directory Server implement it. SYNC seems to have been proposed by the OpenLDAP crew because when they went to implement LCUP they found that it “requires server implementations to maintain complete history information in order to provide eventually convergent incremental refreshes”, which presumably wasn’t something that OpenLDAP already did. Yet the working group went ahead and progressed LCUP to RFC and not SYNC.

Anyway, moral of the story is that if you want notifications, then you want PSEARCH if you’re using Fedora Directory Server and SYNC if you’re using OpenLDAP.

If you’re using OpenLDAP’s client library, rather than the Mozilla LDAP C SDK, then it’s a little tricky since you have to manually create the psearch control and parse the entryChange controls. Here’s some example code.