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 06:55:14 GMT
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.

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

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

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