directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [asn1] why use TLV objects at all?
Date Thu, 24 Feb 2005 17:52:58 GMT
Alan D. Cabrera wrote:

> 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.

I thought this before but I think there may be ways around this :).

>>>>>> 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.
Ok this is different from SNACC4J where POJO is the stub.  Other 
compilers do the same.  The POJO has machinery for populating itself.  
This might not be the best approach in which case I like your's here 
better.  Basically the stub is the high level decoder encoder.

>>>> 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