On Wed, 2002-07-10 at 01:08, Kai Krueger wrote: > ----- Original Message ----- > From: "Simo Sorce" <[EMAIL PROTECTED]> > To: "Stefan (metze) Metzmacher" <[EMAIL PROTECTED]> > Cc: "Samba Technical" <[EMAIL PROTECTED]> > > >Hi metze, > >on top of the first doc I see you state that all strings should be utf8. > >I hearteadly disagree, I woul d rather like to see all internal strings > >on new code to be UCS-2. > >Utf8 has many disadvantages: > >1. require any RPC requests that comes from clients to be converted > >forth and back (UCS-2->UTF8->UCS-2) > >2. Is difficult to manipulate UTF8 strings as they are variable lenght > >multibyte chars and sometimes uppercase chars have different lenght than > >lowercase chars. > With UCS-2 the usage of DEBUG() and other string functions might be a lot > more difficult than with UTF8 as it would require to use smb_ucs2_t instead > of char*.
It is not really a problem, we only have to build up a DEBUG function that converts to ascii before printing (and we should do the same with utf8 too afaik), debug statement performance is not so important imho. > The decision about character encoding is very important and should be agreed > upon by all samba members so that it can be used in all future interfaces. I agree, I hope also tridge may contribute to the discussion, as I had many talks with him about this issue in the past and we agreed that using ucs2 internally was the best compromise. > The second point (where should access checks be done) again was only a > reminder. > In discussions on #samba-technical there was more or less a consens, that it > is safer > to have the access check in the sam functions rather than in the callers. I tend to agree, but are we sure we always have a valid NT_USER_TOKEN when we need to access the sam? I'm thinking of accounts administration, migration, backup, and so on. > This way > access checks can not be forgotten and there will be consistancy across all > functions that will use the interface. To acompany this change, the second > document (SAM-interce_handles.txt) was written, which is a successor (or > alternative) to the first interface spec. This document seem good, but I would really prefer to smb_ucs2_t types in it :) Simo. -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399
signature.asc
Description: This is a digitally signed message part
