[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANONYMOUS SASL profile
From: |
Simon Josefsson |
Subject: |
Re: ANONYMOUS SASL profile |
Date: |
Wed, 14 Dec 2005 16:14:37 +0100 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
Francis Brosnan Blazquez <address@hidden> writes:
> El mié, 14-12-2005 a las 10:29 +0100, Simon Josefsson escribió:
>
> Hi Simon,
>
>> > anonymous_token = gsasl_property_get (ctx, GSASL_ANONYMOUS_TOKEN);
>> > g_print ("Anonymous auth requested: %s\n", anonymous_token);
>>
>> What type is 'ctx'? It must be of the Gsasl_session type, not Gsasl.
>>
>
> This was the problem. I was using the Gsasl context where the Gsasl
> session was expected. It works fine!
Great!
> What I don't understand is why gcc didn't drop me an error. I'll check
> it.
It should have...
>> The idea is the have one Gsasl context per application, and one
>> Gsasl_session for each client/server session in the application. This
>> is to make it as lightweight as possible.
>>
>> Creating a Gsasl context for each session is slightly more expensive,
>> but compared to everything else I think it is very minor. The extra
>> time will be in gsasl_init, and setting any global callbacks.
>>
>> There is no problem in creating multiple Gsasl contexts in an
>> application, if that would simplify your design.
>>
>
> Well, I think we have to check what we are doing here because we where
> getting some seg faults while reusing the same Gsasl context. That's why
> we started to use a context (Gsasl *) and a session (Gsasl_session *)
> for each connection.
Ok. There shouldn't be any problem. You will get crashes if you use
Gsasl* instead of Gsasl_session*, perhaps you have other such errors?
GNU SASL should also be thread safe for any normal use. You can't
invoke gsasl_step* for the same Gsasl_session in two threads at the
same time, but I don't consider that normal use.
> Simon, thanks for your clear and quickly reply.
>
> BTW, we are using GSASL for the BEEP stack [1] we are working on. You
> could find it at: http://vortex.aspl.es.
Thanks, I added a link to it on the GSASL home page.
> Now that I have you at the other side let me ask you another question
> not directly related to GSASL.
>
> For win32 buildings which compiler/product are you using? The product we
> actually use is mingw. Are you using this also?
Yes. I am using mingw32 as distributed by Debian.
> I asking you this because we are having some annoying issues while
> producing native dll on windows that is not produced with gcc. Actually,
> gcc automatically (well, allows you) to export all symbols from your
> library into the dll. But using other product such us Visual Studio you
> need to do the standard voodo with dllimport/dllexport attributes (or
> using G_MODULE_EXPORT from Glib which actually bounds to the same) or
> especify a module definition (.def file).
>
> But reading how GSASL headers are written I've found that you are using
> "extern" attribute rather than any non-sense stuff such as
> G_MODULE_EXPORT.
>
> Our intention is to keep on using gcc (through mingw) to support Vortex
> Library on win32, but it would be great to also support products such as
> VS. The main problem with VS is that not providing dllimport/dllexport
> stuff (or a .def file) cause not producing the import library (.lib). As
> you know, this actually allows Win32 ISVs to link with the dll produced.
>
> How did you work around this issue on windows for GSASL?
Currently I only support mingw32, not VS. If you can provide details
on how to fix this in GSASL, I'll be happy to install any patches.
Supporting VS seem like a useful thing, if doesn't cause any harm to
anything else.
Some web searching revealed this:
http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/#dll-magic
http://stud3.tuwien.ac.at/~e9725344/gtk/Building_HowTo.html
Perhaps it can be of any help...
Thanks,
Simon