Re: KITTEN BOF at IETF 60?
"Douglas E. Engert" <[email protected]> Wed, 24 Mar 2004 13:19:35 -0600
| Newsgroups | gmane.ietf.cat |
|---|---|
| Message-ID | <[email protected]> |
Greg Hudson wrote: > > On Wed, 2004-03-24 at 09:08, Douglas E. Engert wrote: > > Some situations which need to be addresed: > > > > o application may wish to use one thread model, but GSSAPI > > implementation is using a different model. > > In the long run, this is like saying "an application may wish to use one > stdio implementation, but the GSSAPI implementation is using a different > one." There's just no point in adding complexity for this purpose. I think we agree. I don't want to get into this situation, I want to avoid it, by possibly saying only "native" threading is supported. In the past there have been quite a few competing thread implmentaitons. The DCE threads comes to mind. DCE has Kerberos GSSAPI implementation. > > In the short term, you're also deluding yourself if you think you can > provide good support for non-standard threading implementations. libc > functions, like gethostbyname(), already make use of the native > threading primitives. See > http://www.imc.org/ietf-sasl/mail-archive/msg01009.html > for more discussion on this point. > > > o Applicatin may wish to use multiple mechs but the mechs > > use differnet thread models. > > ... which is why platforms should provide one standard implementation > (perhaps with multiple APIs, like on Solaris, but they must > interoperate), and all libraries should use it. I believe platforms are > pretty much all doing their side of the job correctly at this point. Yes I like the Solaris mechglue, which really requires GSSAPI to be as Generic as possible, so as an application will never need to make mech specific implementation calls to store a delegated credential for example. > > > Any thoughts on doing something like OpenSSL does with callbacks for threads? > > I think OpenSSL and cyrus-sasl went in the wrong direction here. What > they do is really unfriendly to callers who are themselves thread-safe > libraries. > > If one is dead-set on providing callbacks for non-standard thread > implementations, a better model is glib's, where specifying alternate > thread callbacks is optional (and rarely used). I am not set on it, just bringing up the issue. OpenSSL is used internaly by may applicaitons and some gssapi implementations. -- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to [email protected]