On 8/11/10 10:21 PM, Alex Karasulu wrote:
On Wed, Aug 11, 2010 at 11:16 PM, Alex Karasulu<[email protected]>wrote:
Hi Emmanuel, Kiran, guys n gals,
On Mon, Aug 9, 2010 at 9:19 PM, Kiran Ayyagari<[email protected]>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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
