emboss/krypt-core — comment on commit 9c1565bc3b78536e4c9889fa2ea4f566e0e925eb
File:  line 0
By emboss:

>OK, that's our new ASN1InputStream(new ByteArrayInputStream(obj.readObject()));, right? :)

Well, now that you say, sort of, yes :) I tried to mimic JRuby's superb IOInputStream. I felt that for Asn1.decode to fulfill POLS, I would have to support StringIO, when I support generic IO and on top of that String should also be supported for mere convenience. So I told myself how cool it would be to have something that abstracts away the details and simply let's me operate on it using the standard C I/O like read, write, seek, close etc. That interface is now krypt_instream. It operates on byte arrays, file descriptors, and objects that support IO#read and IO#seek.

The Asn.1-related streaming principle is then introduced in krypt_asn1_definite.c and krypt_asn1_chunked.c. They are my FilterInputStream ;)

>I'm still not clear about 'Header' and 'value_io' are good names or not, but you can change later if you need.

I'm not too proud of "value_io", too :) On a cursory glance I didn't find good examples on what idiomatic Ruby name for methods that return a IO is - do you have any suggestions? Why don't you like "header"? I'm not saying it's perfect, I just read an article once where the person referred to the unit of Tag and Length as "header", so it kinda stuck with me. But I'm open to alternatives - it's just that I couldn't find any better :) I also don't like OpenSSL's "object", because in my opinion, Tag and Length don't represent the object yet - it's Tag, Length *and* Value :) That's why I used krypt_asn1_object for the combination of krypt_asn1_header plus the value bytes instead.

>OT: When I implemented OpenPGP and ASN1 as a firmware of HSM years ago, there's no IO in HSM so I wrapped heap memory as an IO-like class and implement methods as ptr operations without memcpy. Of course IO would fit krypt.

That sounds interesting, tell me more about it! (BTW: I'm scared, the more C I write, the more I start to like it ;) What do you mean by without memcpy? You allocated heap memory and operated on it in place? Sounds efficient :) Do you think something like it would work for https://github.com/emboss/krypt-core/blob/master/ext/krypt/core/krypt_io_in_bytes.c, too?