directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: [kerby] ASN1 Quick review
Date Fri, 25 Dec 2015 01:09:41 GMT
The third approach looks good to me, we might probably prototype it in a branch and see the
effect. The priority to me would be low, if the result looks nice then we can target it for
1.0.0 or later?

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Friday, December 25, 2015 12:06 AM
To: kerby@directory.apache.org
Subject: Re: [kerby] ASN1 Quick review

Ah, crap I should have posted this mail to the Kerby mailing list...

Will do that starting from now.


Le 24/12/15 14:07, Zheng, Kai a écrit :
> Nice comments! Let me focus on something to explain. 
>
> Regarding merge AbstractAsn1Type and Asn1Encodeable. As I said before, the former wraps
a Java value, the latter does the encoding/decoding dirty work. The separation may does no
good so far, but would also do no hurt for the left. Something may start with the latter and
doesn't like the generic thing. How about if we make the parser results encodeable/decodeable?
On other Java platform that doesn't support the generic thing very well? How about if we bridge
this library to other ASN1 stuffs? Yes as you said these are just maybe, uncertain things.
But if the merging doesn't generate some good for now, I thought it may be not bad to go the
way.
>
> I guess you're mentioning two approaches: either let the ASN1 objects do encode/decode
themselves, or have some help class to delegate the dirty work out. Yeah this is an architecture
decision that's done when coming up the first piece of the codes. I remembered I tried many
times, but never got a way that works perfect in every aspect. We used the former approach
that goes not bad so far if we don't attempt to support many other coding rules and do BER/DER
as good as possible. 
I see. It would be a real pain to have a class having a encodeBer(), encodeDer(), encodeWTFer()...
methods into it.

May I suggest a third approach ? The Visitor pattern might be a good candidate here : https://en.wikipedia.org/wiki/Visitor_pattern

The idea is to delegate the encoding to a visitor, that will use the right encoding type.
We decouple the encoding/decoding from the value classes. It adds a bit of complexity, but
in our case, this might be the correct approach.

Mime
View raw message