directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [asn1] why use TLV objects at all?
Date Thu, 24 Feb 2005 06:14:33 GMT
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.

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

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? 

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.

    -Alex
















Mime
View raw message