[Draft #2] Samba 3.0 roadmap...idmap storage & central idmaprepository

[Simo Sorce]

On Wed, 2002-07-10 at 01:08, Kai Krueger wrote:
> ----- Original Message -----
> From: "Simo Sorce" <simo.sorce at xsec.it>
> To: "Stefan (metze) Metzmacher" <metze at metzemix.de>
> Cc: "Samba Technical" <samba-technical at samba.org>
> 
> >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 - simo.sorce at xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20020709/a5e85ae0/attachment.bin