>>>>> "Sam" == Sam Thursfield <[log in to unmask]> writes:

    >> A dependency on glib is fine provided that  it won't be a problem.
    >> 
    >> note that I was expecting a synchronous interface; I was expecting you
    >> to run any event loop you needed while calls were in progress.  Your
    >> code will need to deal with being entered from multiple threads at the
    >> same time; running multiple event loops is a fine solution to this
    >> assuming that each thread ends up with its own socket to dbus and this
    >> works on Windows.

    Sam> That simplifies things for me. I presume your plan is to call
    Sam> get_identity() from a separate thread then so no UI blocking
    Sam> occurs. 

Well, something like the ssh command line app just blocks.
One hopes something like pidgin calls GSS from its own thread.
IN practice, I suspect we'll find some people who forget that GSS is
allowed to block and produce non-ideal experiences.
But that's an app bug and until GSS has an asynchronous API, we don't
have a lot of options.

    Sam> Multiple calls will be fine (although I'm confused why an app
    Sam> would need to request multiple identities simultaneously)

When my pidgin starts up I log into about 5 chat services.
I only have one mail account on my desktop, but I know a lot of people
who have several.

    >> So, I said that glib was fine provided that it didn't introduce
    >> problems. The GSS-API mechanism is loaded into a process indirectly. A
    >> process will not typically know that it is using moonshot and so it will
    >> not link based on things moonshot does. The process may or may not be
    >> threaded; the process may or may not link to a threads library. On some
    >> platforms, such as Linux, linking to a threads library in a plugin has
    >> some interesting effects, for example mutexes initialized before the
    >> threads library is linked may not be used after the threads library
    >> joins the process.
    >> 
    >> I don't remember if we pull in the pthreads library; we use thread
    >> specific data and mutexes, but I don't think we actually use things not
    >> in libc. I don't remember if any our dependencies pull in the threads
    >> library.
    >> I don't remember if glib always pulls in threads.
    >> If not, you could run into trouble if a non-threaded application used
    >> glib, pulled in threads via a plugin that also depended on glib and
    >> mutex or other state is inconsistent.
    >> 
    >> Similarly, we need to wkr if the application uses QT. Can you use glib
    >> and QT in the same application?

    Sam> Good points. I don't think there are many desktop apps on Linux that
    Sam> don't link to GLib already, and since GLib 2.24 GObject initialisation
    Sam> - 
    Sam> g_type_init() - has automatically initialised threads. Qt uses the
    Sam> GLib main event loop on Linux. So I don't think there is anything to
    Sam> worry about, but of course I can't promise without a list of the apps
    Sam> you will be linking to because there is always a corner case hiding
    Sam> somewhere.


Worst case: someone uses us for ldap authentication to something they
use as their nss passwd or group provider.
In that case we get linked into every application on the system.


    Sam> The one thing that could be an issue is if an app has been statically
    Sam> linked to a different version of GLib to the one on the
    Sam> system. However, this is a potential problem with any of your
    Sam> dependencies and is really a problem with the app.

I'd kind of hope that system dependencies would use version scripts and
symbol versions to support multiple versions of the library in the same
address space.  Getting that right for Kerberos was tricky.  The desktop
world seems to tolerate a lot more library churn than system libraries
do.
We'll see how bad this hurts in practice, but long term this is the kind
of thing that GSS mechanisms need to tolerate. However, I haven't vetted
other dependencies of the project against that sort of standard, so
don't worry about the multiple versions in the same process space issue
now.

    >> My suspicion is that it's probably fine to depend on glib, but someone
    >> familiar with glib implementation would need to consider the issue.
    >> 
    >> Since we're looking for a synchronous API, it seems like you could wrap
    >> your glib dependencies fairly easily.

    Sam> Yes, there's certainly no need to depend on GLib on Windows if we
    Sam> don't have to worry about asynchronicity.

    >> IN response to the MSVC support.  You need to produce an msvc compatible
    >> import library.  Your library needs to have an ABI that can be called
    >> from MSVC. (I think that means no C++ in your exposed ABI). Your public
    >> header file needs to be something that can be included from MSVC.
    >> 
    >> I don't think it is a requirement that your dll be buildable with MSVC,
    >> particularly if you build it as part of the existing moonshot-ui package
    >> which already requires mingw.  I don't think libtool in mingw mode
    >> produces import libraries, but I believe it's fairly easy to produce
    >> them from what it does build.

    Sam> Great, this is the easiest option. MSVC is required to produce
    Sam> MSVC-compatible import libraries from a dll, but it is not difficult.

I thought the mingw site had a procedure to turn a .a import library
plus a dll into a .lib. but it may have used msvc tools under the
covers.