July 4 is a holiday here but you managed to send this mail just as I was
checking e-mail for another reason.

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

    Sam> Hi!
    Sam> Another request for information on your requirements for the C stub library.

    Sam> First, Alberto has pointed out that "stub" can mean code that you will
    Sam> directly include (cut and paste) into projects, while library of
    Sam> course means the opposite. Are you after a libmoonshot shared library
    Sam> in its own package, or something else?

Stub here comes from RPC systems which often call the trivial part of
the RPC--the part on the client that wraps the request or the part on
the server that unwraps the request--a stub.
We want a library.
It's fine if the moonshot-ui package generates the shared library and
installs it; it's fine if that's a separate package completely.
For debs and rpms we'll of course generate library and dev/devel
packages. But we can do that regardless of what you do above.


    Sam> Secondly, I don't know if you're aware but access to D-Bus from C is
    Sam> generally done bound to a specific platform library - ie. GLib, Qt
    Sam> etc. This is because D-Bus requires a message processing system -
    Sam> ie. an event-driven main loop. If you'll be making D-Bus calls from
    Sam> mech_eap, or linking to a library that does, this essentially adds a
    Sam> dependency on GLib, and a requirement that a GMainLoop is running
    Sam> while the DBus calls are being processed. Using libdbus directly is
    Sam> discouraged[1] and would be much more work.

    Sam> Attached is a draft of the API. Currently I've exposed a few GLib
    Sam> primitives, but it would be possible to wrap these so that GLib is not
    Sam> a dependency on Windows.


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.

gss-api is a synchronous API; there are some discussions of an
asynchronous version, but doing that requires an indirection layer so
you are not dependent on any single event loop. Anticipating that
complexity seems premature.
(Redhat has a solution they are proposing for use in MIT Kerberos, but
again, way too early for us to care)


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?

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.


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.

Your API looks good for a asynchronous version of the API.