transitioning release management

[simo]

On Wed, 2008-02-27 at 14:19 -0500, Derrell Lipman wrote:
> On Wed, Feb 27, 2008 at 2:15 PM, Volker Lendecke
> <Volker.Lendecke at sernet.de> wrote:
> >  What would your extensible API look like?
> 
> The big change is that instead of the user manipulating structure
> members in the context structure, the context structure will become
> entirely opaque, and setter and getter functions will be used for
> changing it.  This allows me to make changes to the internal context
> structure, typically for adding new functionality, without affecting
> the ABI.  While I'm at it, I'll clean up the use of the different
> types of option settings (there are currently three different
> mechanisms in use!) and the authentication callback function.

This sounds reasonable, but to be honest I'd like to gain something from
breaking API/ABI. Breaking API/ABI means distributions may need to carry
on a libsmbclient-compat package, so it's better if the difference
between the 2 is because of functionality change and not just interface.

> >  Assuming that my proposal for the async client libs is
> >  something that we want (I definitely want this), is there a
> >  sane way we can expose this async functionality to the user?
> >  And, is there a sane way to plug into different event loops?
> 
> The event loop stuff all happens "under the hood" right now.  The user
> has no control over it.  (All functions are synchronous.)  It will be
> possible to make changes for async usage later, keeping the existing
> functions as wrappers which call the send and receive functions like
> the wrappers in Samba4 do.

Right now there is simple no real event loop, but adding an event loop
later is not simple, especially if you want to make it pluggable (and
you want to for a library).

> >  While there, what are the important event architectures out
> >  there that we need to support? glib? Do they have one? KDE?
> >  libevent? What else is out there?

glib has it's own event loop that all gtk/gnome apps use
qt has its own event loop that all qt apps use
So we probably want to support at least glib, qt and samba3/4 event
loops.

> dbus is what's used by KDE and seems to be quite popular.  I haven't
> yet had an opportunity to look into it in depth, but it's on my list
> of things to do "one of these days".

err, dbus is about another kind of events afaik (available for all
environments nothing specific to KDE).

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>