directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Attributes and DN question
Date Sat, 13 May 2006 16:12:05 GMT
Emmanuel Lecharny wrote:
> Thanks Alex for the comments.
>
>>> I've created it. It mixes ModificationItems and Entries, with a DN, so
>>> we cover all the cases.
>>
>> Did you have a look at the existing LDIF classes in shared-ldap ? 
>> Were they inadequate .. I know some features were not there.  Also 
>> years ago Jeff Machols had worked on some LDIF code in the clients 
>> libraries.  Unless there is some extra ordinary reason we should not 
>> reinvent the wheel?
>
> You bet I did ! I used them too, because they where there. It's 
> difficult to reinvent the wheel on such a matter, because RFC 2849 is 
> so restrictive that it does not leave you with many room to show how 
> smart you can be !!! However, the actual implementation has some 
> problems :
> - DIRSERVER 604 ( support of :< file://...)
> - DIRSERVER 618 ( support of changetype attribute )
> - DIRSERVER-187 ( multi-lines not accepted ) (Was DIRSERVER-199)
> - Added Control handling
> - There is a bad bug in value handling : "cn:valid name" is 
> transformed to cn -> 'alid name' (the 'v' is deleted)
Heh this is good enough reason if you ask me to start from scratch  :). 
Lot's of problems thanks for addressing them Emmanuel.
>
>
> So I just considered reuse a LdifReader I wrote last year, before I 
> knew about ADS (and it was the reason I lookad at ADS : I wanted to 
> know if the Ldif Reader implementation was better than mine, and at 
> this point, I was totally fascinated by the work done on ADS, so I 
> stopped working on ldif). It was a piece of software I ported from a 
> previous C# implementation I did too.
>
> I don't know, at this point, if it can be called a NIH syndrom ? May 
> be a little bit, because I didn't had the feeling to fix the existing 
> code while mine was almost working, so I decided to merge both, 
> resuing ( with small modification) LdifEntry (renamed to Entry to 
> avoid code breakage)
No this my bad.  I did not know just how bad a state the current LDIF 
reading code was.  Again thanks for tackling these issues.
>
>
>>
>>> btw, I'm not sure that allowing the server to injext a ldif file
>>> whenstarting is such a good idea... Let me elaborate a lil bit : what
>>> if your server is restarted? The ldif will be injected again. And that
>>> may not be the expected behavior. wdyt ?
>>
>> The server puts an entry into the ou=system area about the ldifs it 
>> loaded.  It remembers what it has loaded. This is not the greatest 
>> thing in the world but it was a great way to get apps built on top of 
>> apacheds to
>> load an initial LDIF file. 
>
> Ok, cool ! I wasn't aware of that. Makes it totally sane, then. At 
> least, for embeded servers, it's a much better solution than to force 
> the user to import some data using an API. Forget about my objection.
You do have a good point about this potentially being an issue.  I think 
we should consider it again.  I just don't have much juice right now to 
put much thought into it.
>
>
>>>
>>> It could be better to have a tool to inject Ldif entries and changes
>>> into the server (like LdifDe). IMHO :)
>>
>> Well there is the apacheds-tools module.  I intended to put this 
>> functionality there as well as some command line clients.
>
> I gonna check that. I guess it's in sandbox, so I will ressucicate it.
It's actually in the main trunk and in the 1.0 branch.  It's got the 
client code to do a graceful shutdown and things like that.  It's the 
tools module in apacheds/tools.

HTH,
Alex


Mime
View raw message