On 8/14/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > ... > - an interface KerberoFlags > - an abstract class AbstractKerberosFlags implementing the base > operations, and extending the asn1 BitString object > - 3 classes extending AbstractKerberosFlags, containing the > combinaison of flags (TicketFlags, KdcOptions and ApOptions) > - 3 enum containing the different individual flags (TicketFlag, > KdcOption and ApOption) > > It will ease a lot flags manipulation in the code, and be coherent > with our current ASN.1 codec. > > thoughts ?
In general I like the clean-up, but we do have enumeration using the older Java-style int's and we do have these classes and they already extend the common base class Options. KerberosFlags is a new name from RFC 4120 (as opposed to RFC 1510) and I agree the rename is in order. Regarding easing flag manipulation, I haven't found flag setting to be a problem and I'm not sure how what you propose helps. So, what's the major benefit of this work? Is this part of the "make codecs 6x faster" and "remove BC deps" initiative? What happens with the concept of making Kerberos ASN.1 classes implement common codec interfaces, such as "Encodable" and "Decodable." I thought one of the ideas you were working to make uniform was that the classes would know how to encode themselves, which to me ment something like a getEncoded() method that returned a byte array containing the DER or wrote to a ByteBuffer. Also, if I found the right BitString you're talking about, extending BitString would expose a public API that has nothing to do with flags, such as isStreamed(). These classes really should be immutable, even though they aren't today. After decoding off the wire, they should be immutable. The client side needs to set flags during request building, though. Do you have examples yet of how you've updated Kerberos message objects to use the newer ASN.1 codecs? I thought you checked in a class or two, but I couldn't find them. Enrique
