Managing DNs in libads only in utf8

[simo]

On Tue, 2007-02-27 at 13:09 -0600, Gerald (Jerry) Carter wrote:
> -----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?

Cause Jeremy's patch is a noop ?

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

This may be true, but I still hope we don't reason by absolutes and
decide case by case on the merit of the code.

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

yup

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

+1

> (b) solves the supplementary group problem you
>     pointed out, and

+1

> (c) Does not compromise the integrity of the wire
>     boundary design we have not for converting strings

I vote to not compromise the integrity using a strong boundary in the
code I'll propose (Volker's struct).

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

My call, I rather prefer to see my patch reject and being told WONTFIX
than not trying to enhance our code at all.

But if WONTFIX will be the answer I will like to raise the question of
being more radical than what we are wrt support of non utf8 charset as
pointed out in the answer to Jeremy.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org