RE: Kerby client library refactoring

Thanks Emmanuel for the feedback and sorry for the late response as focusing on the ASN1 things. >> If those elements are going to be Enum, keep in mind that you can inherit >> from another enum. In current Kerby codes, for options and flags, we favor using the Java enum keyword as a better

RE: Kerby client library refactoring

Thanks all for the confirm! Will be back and proceed for this sometime later. Regards, Kai -Original Message- From: Zheng, Kai [mailto:kai.zh...@intel.com] Sent: Tuesday, November 24, 2015 1:59 PM To: kerby@directory.apache.org; d...@directory.apache.org Subject: Kerby client library

Re: Kerby client library refactoring

Le 26/11/15 12:44, Zheng, Kai a écrit : > Thanks Emmanuel for the feedback and sorry for the late response as focusing > on the ASN1 things. > >>> If those elements are going to be Enum, keep in mind that you can inherit >>> from another enum. > In current Kerby codes, for options and flags, we

Re: Kerby client library refactoring

One other thing I was thinking is if we could make the options more object oriented. Like instead of having name value pairs we have getters/setters. On Nov 24, 2015 12:59 AM, "Zheng, Kai" wrote: > There are good feedbacks from Steve recently. Based on discussions with > him

RE: Kerby client library refactoring

Thanks Marc. An KOption is an enum value, and KOptions is essentially a map that does optionName -> optionValue. You mean some getters/setters for KOptoins? For what? Now there're already some methods to operate a KOptions. Maybe a simple example code? Thanks. -Original Message- From:

RE: Kerby client library refactoring

Oh, no bad at all :). Just as you did, I did think about coming up some enum or the like that's extensible because I wanted to share common options and related codes between krb client side and kdc server side. The overhead was not paid so I gave it up. Regards, Kai -Original Message-