On 06/20/2011 04:06 PM, Rob Crittenden wrote:
Take a look at ipalib/constants.py, it is full of containers like this.
It is hard to review this patch without seeing how it will be used in
the framework, are you planning on replacing all of these with DN
Yup, I'm aware of these. There are two easy solutions:
1) Leave the containers as they are. They can always be used with DN
class. This is another one of the reasons the DN class accepts DN syntax
(for legacy and simplicity). The existing containers are all simple
DN's, their encoded value and decoded values are identical. So as long
as any programmer who adds a new container understands the encoding
rules all will be good. (The problem with your example test was simply
you didn't use the constructor correctly. See "[PATCH 28/28]" for just
one way to construct a DN using the existing container and base strings
as we currently have them defined.)
2) Convert the containers to DN objects. From a robustness point of view
this is preferred. Converting them would be trivial. Once the containers
are DN objects the programmer can't make unintentional mistakes and the
objects combine correctly. The problem we were having is you CANNOT
treat DN's as simple strings, they aren't simple strings, they are
complex objects which in some instances are equivalent to simple strings.
My thought was to do the conversion to DN objects incrementally. I
deliberately wrote the classes to support incremental migration. We
start with the bugs which we know are due to problems with DN handling
and convert those first on an as needed basis rather than as a
potentially large disruptive modification.
The bottom line is we need to have some way to form DN's correctly from
pieces and pick DN components apart into component pieces again. We want
common utility code to do this and not have everybody take a crack at it
in isolated cases when trying to fix bugs. We also want it to support
our legacy implementation and be simple to use (at least those were the
goals I tried to hit).
Multi-valued RDNs are 100% guaranteed in IPA so the easier it is to work
with them the better.
I believe the classes make handling multi-valued RDN's quite easy.
It's just when you start to try and explain things it seems easier to
not fill the explanation with a bunch of caveats. If you understand
mutli-valued RDN's and the AVA's they're composed from the classes will
make perfect sense and combine easily.
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
Freeipa-devel mailing list