On 11/06/2019 17:43, Radovan Semancik wrote:
I would be interested about having an exhaustive description of the
differences.
E.g. AD objectclass definition for 'person' looks like this:
Completely different form. Part of the data is equivalent. But there
are extensions (e.g. showInAdvancedViewOnly). Syntaxes are all
different. Auxiliary object classes are handled in a different way
(they can be "included" in structural object class definition). Lots
of subtle differences there.
OMFG...
But the most annoying is objectCategory. AD obviously cannot properly
index objectClass. Therefore they have invented single-valued
objectCategory. That is the primary reason that I have bothered with
this.
I have no words.
To be completely honest, all of this leaves quite a bad taste. I do
not want to go into all the gory details. I think I will keep the
implementation to the bare minimum to be able to survive with AD.
Makes sense.
Can't wait for M$ to stop using Windows and switch to Linux. Even if I'm
pretty sure they are going to Fxxx it up quite a bit.
AFAICT, you are working in a branch, which is just fine. I don't
think the LDAP API base code will move a lot in the coming weeks, now
that we have cut a release, so you have time to do what you need and
be safe merging all of it back in master.
For now the code is in my AD connector for midPoint. That's where it
is easiest for me to have quick trial-and-error cycles, that are so
necessary whenever one works with AD. Once I'm OK with the code I'll
move it to Directory API. But that will take several weeks/months.
`
Makes sense.
Current structure of Directory API, especially the schema-processing
parts (SchemaLoader, SchemaManager) is not ideal for this particular
kind of abominations.
trudat. I saw that you made it extensible, which is a sane decision.
May be creating an abstract classin the middle would make sense, I
don't know. Or a factory ?
I do not know yet. Honestly, I'm not sure that I completely understand
current purpose of SchemaLoader/SchemaManager and how the
responsibilities are split between them. E.g. it looks like the design
is based on assumption that all the schemas will be in RFC4512 format
(or something very similar). Which obviously does not fit AD schemas.
But I'm not sure. I think I need more experience with the code to
understand it. Maybe more experiments. And I also have almost zero
understanding how all of that fits into the server. That is also the
reason why I've done only a very minimal changes. I do not want to
ruin original design just because I do not understand it yet.
The original idea was to stick to the RFC as much as possible (well, at
the very beginning it was all about adhering strictly with the RFC,
something that quickly became too rigid, as you realized).
The second aspect was about being able to modify the schema without
breaking anything (which means a two step update : you modify and check,
if it does not break anything, then you commit). There are many checks
being done, accordingly to the relation between the various schema
objects (like you can add an OC if the AT it uses aren't existing, etc).
That were the two drivers for the system.
We added one more : the ability to inject some new schema element using
a classloader (that was for extension of elements like
schemaCheckers/normalizers and comparators). Those are no defined in the
RFC, but we need them in ApacheDS.
Actually, decoupling the API from MINA will be quite difficult. We
can discuss that further, but the main issues are :
Yes. That is something we need to discuss later. The primary problem
with MINA is its complexity. E.g. it makes it very inconvenient to use
Directory API in simple apps, because even the basic usage of the API
creates a lot of threads. And then it is a complete nightmare to
diagnose and fix issues, e.g. the recent issue with the bind. Such
things should be easy on the client. But they are not. I understand,
that there is a need for some of that complexity on server side. But
maybe, if we can make the "networking underside" pluggable, then we
can have MINA on the server and something simpler on the client. But
that is also something that needs to wait a bit. One problem at a time
...
The main issue is the fact the API is asynchronous. It makes
*everything* insanely complex. Anyone claiming concurrent code is simple
is either a genious or an imbecile.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
