Hi,
Honestly I say, I do not know the deep inside of both LDAP and
OpenLDAP implementation, but I understand this project is;
LDAP for CODB ( or LDAP as a engine of CODB ).
I think it is better to focus to replace filesystem based CODB to
LDAP (or some other types of DB system) based one, for
performance enhancement.
I think that LDAP should be dedicated to CODB. Not for the other
LDAP service. At least me, I understand Patrick's proposal
is *not* "adding general LDAP service to BlueQruartz first, then apply
it to CODB".
I understand it is a project that "using LDAP for CODB enhancement".
If I am misunderstanding your notice about the multi-master replication
feature. If that feature is important for CODB function, OpenLDAP
might not be usable....
Regards,
Yasu.
P.S.
Now I am traveling US, west coast. Sorry for my slow response.
On 2008/01/05, at 0:53, Atopian wrote:
> One of the biggest drawbacks to openldap is the lack of a proper
> dynamic ACI. FDS is based off of the same code base as NDS/SunOne/JES
> Ent LDAP. In addition to proper ACI support, it should have the
> multi-master replication features that openldap lacks (note this data
> is ~6-12 months old, feel free to correct me if the landscape has
> changed). Having to restart openldap everytime a permission changes
> (site is added, etc) is a very unpleasant idea.
>
> That being said, grats patrick for doing something I have wanted to
> see done to the old cobalt backend since I was at cobalt :)
>
>
> On Jan 3, 2008 4:34 PM, Yasuda Yutaka <yasuda (at mark) mfc.bakkers.gr.jp> wrote:
>> Hi Blues,
>>
>> I am very interesting about Patrick's project (of University?) and I also agree Brian.
>>
>> First, to replace CODB, the point is how implement the compatible CODB API using LDAP system.
>> Of course you may need to modify or add some tricks to enhance the response time or just for tuning to get better effect. But even so, there is no needs of GUI.
>> As Brian mentioned already, another path to modify database will make conflict easily.
>>
>> And the second, I prefer to chose OpenLDAP because it will be maintained continuously in long term, without too much aggressive change, I guess. It is important for BlueQuartz that independence and continuation.
>>
>> Thanks, and I wish you to have great new year.
>> Yasu.
>>
>>
>>
>>
>>
>> On 2008/01/03, at 8:36, Brian N. Smith wrote:
>>
>>>> please help out by telling me which is better
>>>> and included your own opinion.
>>>
>>>>> Openldap vs. Fedora Directory Service (FDS).
>>>
>>> My two cents.
>>>
>>> It looks like Fedora Directory Service is a whole management platform. BQ does not need a whole management platform, as it already is one. To try to integrate the two of them would kind of seem pointless since BQ uses it's own UI API. You would either have to recode all of BQ UI or recode all of FDS UI. The second thing would be to make a handler service. Remember CCE calls the Perl handlers to do all of the magical backend. If you plan on using FDS, you will have to redo all of the handler stuff to make sure that everything gets built/modified/deleted, etc.
>>>
>>> I would think using Openldap as the basis to remove CODB would definitely be the way to go. I have never jumped into the way that CCE works with writing to the CODB stuff, so I have no idea how hard it would be to integrate the two. I think though by adding on the complexity of FDS would ultimately be pointless, as your just reinventing the wheel.
>>>
>>> Now, on a side note. To have it to just CHECK, that may be something, but any LDAP query browser will work just fine as well.
>>>
>>> Good luck though!
>>>
>>> Brian
>>>
>>>
>>
>>
>>
>
>