directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Tence <>
Subject Re: [asn.1] sitedocs update for 0.3 dev cycle - new refactoring page is up
Date Tue, 25 Jan 2005 11:29:27 GMT
Sounds a sensible approach. I'm on it.

- Vincent

Alex Karasulu wrote:
>>Also on a separate note.  Perhaps I've done the wrong thing here in 
>>>trying to get others interested in asn1 by refactoring it.  A massive 
>>>restructuring may not have been the best route to go.  Perhaps we can 
>>>see if you can first massage out the Snacc4J deps instead.  I'm 
>>>realizing my approach to cross reactivity might have been flawed  :( .
>>You're doing good here, no worry. There's been a lot of work put into the
>>asn1 suproject obviously and you're right it's pretty hard to just jump in 
>>and understand everything straight. Focusing on the snacc dependency is a
>>good idea. Do you have more details on this?
> Well yeah I had an crazy (overdone) solution outlined in the JIRA on this:
> Half the stuff I said is a crock of %2&^@%#(s^@F#.  Perhaps I was out
> of my mind.   
> However I've changed my mind on the approach and think the best way to
> do it is to just  embed the bytes into the testcase in a byte array for the PDU.
> You can use the LDAP common library to generate the PDU by setting the
> provider to use the Snacc4J  and dump the result to a file.  Then use the
> contents of the file to build the byte[].  Basically instead of all this XML and
> base64 stuff just put the bytes into a testcase constant and the Req/Resp
> object used for the comparison is also a testcase constant.
> Then you can decode the byte[] with our asn1 lib and compare with this
> object.  Conversely you can encode with our lib and compare with the 
> byte[].
> It does stink that you have to write a little program for generating the PDU
> and generate one for each test case in the libraries tests.
> Does this help?  
> Thanks,
> Alex

View raw message