directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: [asn1] why use TLV objects at all?
Date Thu, 24 Feb 2005 15:59:54 GMT

Alex Karasulu wrote:

> Alan D. Cabrera wrote:
>> Alex Karasulu wrote:
>>> Alan D. Cabrera wrote:
>>>> Alex Karasulu wrote:
>>>>> Emmanuel,
>>>>> I was just thinking about your position on object creation.  
>>>>> Namely the one that is against the creation of Tuple objects that 
>>>>> represent TLVs.  Your proposal to use pooling of these objects 
>>>>> worries me a bit.  It just makes me think there would be a lot of 
>>>>> synchronization overhead.  I may be wrong.
>>>> I was also concerned by this as it may require that you keep a 
>>>> rough factor of 2 more memory, one for the Tuple structure of the 
>>>> message and one for the POJO that you are creating.
>>> It would be if we were collecting all PDU tuples to form a TLV 
>>> tree.  However the idea is to use and release whatever is allocated 
>>> to the tuple.  In this case, the only time you have two copies of a 
>>> datum (tuple value) is when you are holding on to the value long 
>>> enough to set a stub's property using with the tuple value.
>>> Furthermore if we implement the strategy of streaming a large value 
>>> to disk (say a JPEG photo) then the value is just a URI to access 
>>> the stream later on.  This URI is what is set as the stub property 
>>> value.  So in this case we don't have the double hit as mentioned 
>>> above where a value is in memory in a Tuple and duplicated in the 
>>> value of the stub property.
>> So we only keep a stack of tuples?
> You mean constructed tuples for nesting?  Depends on the stub.  I 
> don't think even that may be needed.  Don't know for sure yet though.

You will not be able to get away from having at least a stack of Ls.

>>>>> However I started thinking, "why create Tuples at all?" Follow my 
>>>>> concepts here for a sec even though we have not been discussiong 
>>>>> these constructs: TupleProducers and TupleConsumers.  A producer 
>>>>> simply emits callbacks to a consumer and they are bound to each 
>>>>> other.  What if the callbacks did not pass in a Tuple as an 
>>>>> argument but the components T, L and V of the Tuple instead.  A 
>>>>> stub, which is like the parser you mentioned, tracks and changes 
>>>>> state as an automaton to populate its properties appropriately 
>>>>> with the stream of Tuple events.  The stub can be a TupleConsumer 
>>>>> - really a tuple event consumer rather.  This would eliminate 
>>>>> object creation overheads and populate the stub. 
>>>> Could you not flatten it even further by making a compiler 
>>>> generated stub act as both the producer and consumer?  This is the 
>>>> tack that I am taking with my "smart" stubs.
>>> I highly discourage this approach.  Reason being the nature of the 
>>> relationship between ASN.1 and encodings.  As you know an ASN.1 spec 
>>> can use any encoding.  Conventionally a protocol specifies an 
>>> encoding and sticks to it so it seems to support your approach.  
>>> This however is not always the case and ASN.1 is being used in new 
>>> ways where alternate encodings are being applied to different data 
>>> structures based on the target: i.e. GSM network clients.  However 
>>> these are not the strongest cases for why you should avoid this 
>>> "smart" stub approach IMO.
>> Each stub is specific to a particular encoding.  It is the POJOs that 
>> are used that are universal to the encodings.
> Ahh ok you mean there's a difference between the stub and a POJO.  I 
> thought the pojo is the stub.  Or are you refering to some base class 
> or POJI?

POJOs are populated by applications and fed into the encoding specific 
stubs.  The decoder specific stubs produce fully populated POJOs.  The 
POJOs mimic the structure of the ASN1 description.

>>> The most important reason is to decouple the generation of encoding 
>>> specific code from the stub compiler.  If you make your stubs 
>>> "encoding aware" then your adding some serious complexity to the 
>>> stub compiler IMO.  Why do this when you can avoid it and gain the 
>>> ability to swap out the encoding at runtime?
>> You have the ability to swap out encodings at runtime, you can just 
>> switch stubs. 
> So interface or base class is the same but concrete implementation is 
> the stub for a particular encoding?

Yes, exactly, the compiler will generate encoding/decoding specific stubs.

>>> The way I like to visualize this is ... there is a common 
>>> representation the stub compiler needs to work with.  Rather than 
>>> read bytes from a stream it responds to tuple events as its input at 
>>> a higher level.  Regardless of the type of encoding at the lowest 
>>> level the stub compiler and the stubs it generates need not be 
>>> aware.  It's sort of like the way javac works with the underlying 
>>> runtime: the compiled code as byte codes are bound at runtime to the 
>>> underlying native code to do the actual work using native code.  
>>> Similarly here I'm recommending that the stub compiler generate a 
>>> stub which deals only with TLVs and at runtime the source/target can 
>>> be a BER, DER, PER binary stream or even a XER encoded ascii stream.
>>> I think perhaps some of your concerns on the stub compiler side 
>>> revolve around finding a tangible way for the antlr based stub 
>>> compiler to generate code that deals with a TLV stream rather than a 
>>> byte/char stream.  I too have this problem - it is not easy.  In 
>>> this regard the approach of making the stub totally encoding aware 
>>> may seem easier to do.
>> IIUC, PER does not use TLVs.  You need to know the structure of your 
>> ASN1 object to decode the stream.
>> Keep it simple.  We may as well remove the layer and generate 
>> protocol specific stubs.
> If you're writing the stub compiler then its your call.  However I'm 
> still not convinced this is keeping it simple.  Have you already 
> finished the parts of the compiler that can handle different encodings?

View raw message