RE: Kerby client library refactoring

Thanks for Yan's great work on XDR, I will review the new JIRAs. Regards, Jiajia -Original Message- From: Yan, Yan A [mailto:yan.a@intel.com] Sent: Friday, February 19, 2016 2:13 PM To: kerby@directory.apache.org Subject: RE: Kerby client library refactoring Thanks for Kai's advice

RE: Kerby client library refactoring

Thanks for Kai's advice. I will do that. Best regards, Yan -Original Message- From: Zheng, Kai [mailto:kai.zh...@intel.com] Sent: Friday, February 19, 2016 2:06 PM To: kerby@directory.apache.org Subject: RE: Kerby client library refactoring Thanks Yan for working on this. I understand

RE: Kerby client library refactoring

<smo...@psu.edu> Subject: RE: Kerby client library refactoring After having an off-line discussion with Jiajia, it seems to be a doable idea to share AsRequest or the like between client and server, and the impact might be not so big as I thought before. In this direction, the newly com

FW: Kerby client library refactoring

Subject: RE: Kerby client library refactoring Thanks Steve for the response and great comments! Thanks all for all the good ideas. It looks good to me to expose KdcOption meanwhile to have some handy shortcuts to set those four very frequently used flags, along with some other parameters. Let's get

RE: Kerby client library refactoring

Ah, see your idea. Yes it looks nice and let consider it. Thanks! Regards, Kai -Original Message- From: Marc Boorshtein [mailto:mboorsht...@gmail.com] Sent: Sunday, November 29, 2015 9:50 AM To: kerby@directory.apache.org Subject: Re: Kerby client library refactoring Sorry, was working

Re: Kerby client library refactoring

-> 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: Marc Boorshtein [mailto:mboorsht...@gmail.com] > Sent: Friday, Novembe

Re: Kerby client library refactoring

Le 29/11/15 02:50, Marc Boorshtein a écrit : > Sorry, was working on some other projects. My thought was instead of code > that looks like this: > > requestOptions = new KOptions(); > requestOptions.add(KrbOption.USE_TGT, tgt); > //requestOptions.add(KrbOption.SERVER_PRINCIPAL, >

RE: Kerby client library refactoring

tion because KrbPkinitClient can always reference/aware KrbOption directly. Regards, Kai -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Tuesday, November 24, 2015 4:33 PM To: kerby@directory.apache.org Subject: Re: Kerby client library refactoring Le 24/11/15 06:59

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

rom: Marc Boorshtein [mailto:mboorsht...@gmail.com] Sent: Friday, November 27, 2015 8:43 AM To: kerby@directory.apache.org Subject: 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 h

RE: Kerby client library refactoring

- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Friday, November 27, 2015 12:06 AM To: kerby@directory.apache.org Subject: 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 focus

Re: Kerby client library refactoring

Le 24/11/15 06:59, Zheng, Kai a écrit : > There are good feedbacks from Steve recently. Based on discussions with him > and Emmanuel, I assembled below thoughts. > > KrbClient and its relatives like KrbOption would be broken down according to > supported mechanisms and functionalities. >

RE: Kerby client library refactoring

It sounds great and will be easier to use these apis to write tools. Thanks Jiajia -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

Kerby client library refactoring

There are good feedbacks from Steve recently. Based on discussions with him and Emmanuel, I assembled below thoughts. KrbClient and its relatives like KrbOption would be broken down according to supported mechanisms and functionalities. Eventually we would have these client side APIs for