directory-dev mailing list archives

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


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?

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

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

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


Regards,
Alan




Mime
View raw message