Managing DNs in libads only in utf8

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

simo wrote:
> On Tue, 2007-02-27 at 12:29 -0600, Gerald (Jerry) Carter wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> simo wrote:
>>
>>>> Your extra code is simply not needed in this
>>>> case. Under what case do we not tell people
>>>> to change to "unix charset = utf8" ?
>>> In any case they can't ?
>>> Why do we have the option at all ?
>> I think Jeremy is looking for a practical example
>> to justify why the code should be changed at all.
> 
> The practical example is the group membership bug 
> I posted to this thread with also a bug report
> we have in our bugzilla.

This does not answer the question of why we
can't say that the fix is to set "unix charset
= utf8".  I hate to say this because I know it
will come back to haunt me, be we don't have
to fix *every* bug. :-)  Or make Samba work in
*every* environment.  That would be an infinite task.

So we have two proposals.  One which requires code
changes and one which does not.  Why should we
pick the one that requires code changes?

> It is obvious we can't make miracles, if you use 
> a KOIR set of characters on disk and you are
> sent a japanese chracter in the file name
> we have no choice but drop it and tell to switch 
> to utf8 to fix such problems.
> 
> But there are cases when we never hit the disk 
> or any syscall, and in these cases I don't see why we
> should be lazy and not fix an easily fixable problem.

I think the argument would be that it is called
maintaining the integrity of the design.  Not "being
lazy".  Adding corner cases increase the complexity
of the design which makes for a worse system with
regards to maintainability.

> The ldap DN stuff is such a thing, and 
> using a struct to hold the string making
> it evident it is not just another char * will
> make it possible to use utf8 strings without 
> easily be mistaken and mix unix charset stuff
> with utf8 stuff.
> 
> I understand Jeremy may still find such patches 
> uncomfortable, and reject them.  I'll take the
> risk, being prudent is ok for me, being conservative
> just for the sake of it just sucks.

Jeremy feels stronger about this than I do.  I wouldn't
presume to speak for him or anyone else.  Obviously
the final vote to accept the change or not can only
be done when there is a final patch proposed.

So it's pretty much up to you if you want to pursue
designing a patch that

(a) uses a struct utf8_t {} as suggested by Volker,
(b) solves the supplementary group problem you
    pointed out, and
(c) Does not compromise the integrity of the wire
    boundary design we have not for converting strings

Tridge may have more comments once he's up.  You just
have to weigh all the opinions and if you feel strongly
enough, write the code and take the chance that the
may not be accepted in the end.  It's your call.






cheers, jerry
=====================================================================
Samba                                    ------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF5IHWIR7qMdg1EfYRAtBIAKDlQNPoUX6H2gw110/fTpaB2ULP7wCfT9FH
sJu4X2j7Qk84eDijymig2mg=
=frrk
-----END PGP SIGNATURE-----