directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Do we need to keep the encoder/decoder Provider stuff ?
Date Wed, 11 Aug 2010 22:26:43 GMT
  On 8/11/10 10:21 PM, Alex Karasulu wrote:
> On Wed, Aug 11, 2010 at 11:16 PM, Alex Karasulu<>wrote:
>> Hi Emmanuel, Kiran, guys n gals,
>> On Mon, Aug 9, 2010 at 9:19 PM, Kiran Ayyagari<>wrote:
>>>> so, wdyt ? Should we keep the machinery that allow us to change the
>>> codec by
>>>> using an environment variable ?
>>> IMHO let us keep it, AFAIU this is transparent to the end or API user
>>> right? if yes, then I think it is
>>> better to remove it in another release.
>>> P.S:- perhaps this will save us some debug headaches, if at all arise,
>>> as we are making great
>>>          level of refactoring for the upcoming 2.0
>> If Kiran is correct about the exposure to the API end user, then I agree
>> with Kiran here unless of course there's a lot of headache you're dealing
>> with because of this Emmanuel. If you feel it's too much of a problem just
>> nix it.
> BTW reverting this change if we have to might not be so hard if in fact we
> feel that need. However if we do add some new capabilities like streaming
> content (if you remember all the Value based work we experimented with) you
> might want to leave it to test codec variation to see if bugs are due to one
> codec implementation. Then again it's not so big of a change to revert if we
> do need it. So it seems I can go either way :-).
Right now, I'm merging all the different Messages (InternaLMessage, 
MessageCodec and API messages) so that we don't have so many translation 
going on in the client and server. That will help to clarify the situation.

OTOH, I think that the provider approach is a good idea, but all those 
callback cr*pities are really a PITA, and I'd like to get rid of them. 
The ldap-api is way more simpler than the server, and it works well, so 
I think there is some room for improvement here.

But let's first clean up the place...

Emmanuel L├ęcharny

View raw message