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

Kai Krueger kai at kruegernetz.de
Tue Jul 9 16:09:01 GMT 2002

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

The two documents metze refers to, are realy only work in progress drafts of
the new sam interface that is planed, although we are close to the point
we can start implementing :-). I included the statements at the top to
remind us
that these points still need to be discussed and later on if a descision was
need to be included in the interface.

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.

The second point (where should access checks be done) again was only a
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.
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.


More information about the samba-technical mailing list