Le 04/01/16 08:39, Zheng, Kai a écrit : > I know and agree with the point you made here. What I would say is that, our > Kerberos implementation codes are still lacking many things and to be evolved > fast. We may see many classes, variables, methods and codes are not > referenced in the existing codes, it's normal because we have so much to fill > yet. Given you have reviewed quite a few of the codes, I guess you might > understand that why we define and write those classes or methods not used > yet, because in many times we follow a RFC spec, or a fixed pattern and make > up many of them, either for completeness, for the future we'll use them at > all, or just for our customers they need the library to do something.
I'm fine with that. It's just that as there is no documentation in the code, it's hard to know where it's coming from, and what it might be good for in the near future. A simple Javadoc saying 'not used atm, will be in the near future', or 'part of a RFC draft http://blah' would help. > > Decrypted result in Kerberos is surely to be passed elsewhere and handled in > various procedures or components, considering it often contains many > information. We just can't do all the logics in a single place because that > would result in a very large function or class. I guess the codes you noted > are still very initial for now, which means we have many things to fill in > the places. Sorry I haven't checked the codes you mentioned, but I would if > our Kerby codes are going to be close to the final status with all the > available functionalities existing in MIT Kerberos already fine implemented. We are talking about releasing RC2, and we already have released a RC1 (Release Candidate) ;-) So maybe it's premature to call it a Release Candidate, and we should name them Milestone ? > Obviously, we're not. Sadly, we won't in a fair term future. Otherwise it's > unfair, Kerberos has evolved past more than twenty years, we just can't catch > up with the mainstream simply in one or two years. The simple fact that our Kerberos Implementation at ApacheDS haven't reach a full coverage of the Kerberos specifications in 10 years is just making your point ;-) Sorry if my mails make you think I find it wrong, I'm just trying to point fingers on parts that, in my opinion, might need some improvements. If I'm lucky, I find bugs, or areas where more work need to be done, and that's the purpose of this review. It's also for me a way to get involved in this code... Thanks Kai ! I'll keep the methods at the moment.
