|
Hi Horst,
After reading the .NET naming guidelines, I agree with your assessment that the bindings should use Pascal casing for methods, properties as well as constant value names. I also agree that classes that need to provide explicit control to developers for when native resources are released should implement the IDisposable interface to be compatible with the .NET Framework's Dispose pattern.
I will update the draft with the naming changes and with the changes to the GSSCredential and GSSContext classes indicating that they implement the IDisposable interface.
Please let me know of any other issues that you may see.
Thanks you very much for your help,
Juan Carlos Luciani
>>> Horst Reiterer <horst.reiterer at mind-breeze.com> 01/29/06 6:02 pm >>>
Juan Carlos,
I am working on integrating Kerberos authentication into a Mono-based
application (possibly the Mono Framework implementation itself if I can
find the time) so that native Kerberos clients can interoperate with
Mono-based services. While starting the implementation, I've come across
your GSS-API C# bindings draft:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-csharp-bindings-00.txt
I'm glad that bindings already exist or are being worked on at the
moment. In the introduction, you mentioned that one of the design goals
"was to emulate the Java bindings specified in RFC 2853 as much as
possible while still taking advantage of C# features such as
Properties". I fully agree here! I must say however that the bindings
IMHO follow the original too closely in some respects. Let me mention
two concrete examples:
a) byte[] acceptSecContext(byte[] inTok,
int offset,
int len);
Methods, properties as well as constant values (e.g. NO_CONTEXT)
violate the .NET Framework coding guidelines as defined by Microsoft
(methods properties and constant values should use Pascal casing). For a
C# developer, it is very inconvenient to work with a library that does
not follow the platform's naming conventions for example. Modifying the
bindings to follow the guidelines would IMHO make it's interface
significantly more intuitive.
Was there a particular reason why you've chosen to follow the Java
naming conventions here?
References:
http://msdn.microsoft.com/library/default.asp?url=""> /library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp
b) void dispose();
In my opinion, this is a very serious issue because this disposal
facility simply bypasses the .NET Framework's Dispose pattern and thus
does not allow developers to handle objects with native resources
accordingly. As a .NET Framework developer, I would expect the following
(modified sample taken from the draft) to work:
// ...
GSSCredential cred = mgr.createCredential(name,
GSSCredentialUsage.ACCEPT_ONLY);
using (cred) {
Oid[] mechs = cred.getMechs();
if (mechs != null) {
for (int i = 0; i < mechs.length; i++)
Console.WriteLine(mechs[i].ToString());
}
}
Unfortunately, it can't because the class does not implement
IDisposable (unless I missed something). My strong recommendation would
be to follow the Dispose pattern in all cases involving native resources
so that language / platform facilities (as demonstrated above) can be
taken advantage of.
References:
http://msdn.microsoft.com/library/default.asp?url=""> /library/en-us/cpgenref/html/cpconfinalizedispose.asp
Does a reference implementation of the draft (or at least class and
interface definitions in source code form) already exist? Please let me
know so that I can decide how to proceed in respect to integrating
Kerberos. If it doesn't, I would be forced to roll out my own
implementation.
I'd be more than happy to provide you with further input for the sake of
maximizing the value for developers interacting with the GSS-API using C#.
Thanks for your time, I highly appreciate your work!
Cheers,
Horst.
|
