Extension: DER streams

[vanrein]

Extension: DER streams

[vanrein]

This structure is now indeed pioneered in an application... for LDAP :)

The LillyDAP routine lillyget_event() in derbuf.c is triggered when data is ready for reading on an input file descriptor. It then harvests the first 6 bytes, demands them to contain the full header, and takes out the tag and header length. It then knows how much more it must load.

In the case of lillyget_event(), the data is read into memory, but the mechanism may be useful for DER streams as well.

A change like this would totally upset the structure of Quick DER, however. The core assumption of Quick DER is that it can point back to contiguous areas of memory holding the elementary pieces of data. And it is not DER determining what is elementary -- it is the application's depth of using DER_PACK_ENTER until it decides to DER_PACK_STORE.

We find examples of that in LillyDAP too. It defines so-called shallow parsers that only get the three main fields from an LDAPMessage, and similarly all but the to-be-determined response fields in ExtendedRequest and EXtendedResponse -- currently located in the msgop.c and msgop.gperf files (but likely to change name in the future, in case we separate lillyget_xxx() from lillyput_xxx() routines).

To conclude, yes it is interesting to consider DER streams, and no it is not feasible given the Quick DER model. If any part of the software can do this, it is the application, and the application alone.