ber_read_OID_String patch

Kamen Mazdrashki kamen.mazdrashki at postpath.com
Wed Sep 23 06:36:56 MDT 2009


Hi Andrew,

On Wed, Sep 23, 2009 at 08:42, Andrew Bartlett <abartlet at samba.org> wrote:
> We hit the need for this at the plugfest, and while metze does not like
> the idea of keeping the binary form in the in-memory structure, I'm more
> open to it.  Most important will be to implement the OID to prefix map
> code, and to store the prefixmap on disk as a string.

In case we don't implement binary prefix map in memory, then we need some 
kind of 'adaptor' code to translate between S4-prefix-map <=> DRS_prefix_map. 
I am about to implement a reference implementation as a torture test
in following few days.
Btw, there is a torture test already implemented, you can find it at:
http://repo.or.cz/w/Samba/kamenim.git?a=shortlog;h=refs/heads/drsuapi_prefixmap_wip
The test decodes all attribute OIDs returned during replication and 
verifies those attributes exists in schema - runs perfectly against W2K3-R3.

>
> We decided on the format 1.5.6.9.<last element with the last two bytes
> wiped to zero>: to indicate a partial OID, and 1.5.6.9. for the 'normal'
> types.  (last bit of oid oid less than 16385)
>

What are the considerations behind this decision?
Frankly said, I can’t see any significant benefits from storing prefix map
this way.
And the biggest problem is - luck of documentation.
If we follow ATDS and DRSR specs from Microsoft we will have a documentation 
for Samba itself - which is great. 
Please consider this. 
It is important for maintainability and for future development.
Right now it is not very easy for new developer to start sending 
patches for Samba. And diverting from the Only-Spec-Out-There shall not 
make Samba code comprehension easier.


BR,
Kamen Mazdrashki
kamen.mazdrashki at postpath.com
CISCO SYSTEMS BULGARIA EOOD
18 Macedonia Blvd. Sofia 1606
Bulgaria
http://www.cisco.com/global/BG/





More information about the samba-technical mailing list