directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbert Reilly (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-604) Support for ":<" LDIF syntax in ApacheDS
Date Wed, 10 May 2006 01:00:08 GMT
    [ ] 

Norbert Reilly commented on DIRSERVER-604:

This note in the RFC and your associated assumption takes care of my immediate usecase (I'm
concerned with a string - and I'm happy to accept that the referenced file must already be
UTF-8 encoded).

Longer term I think there is still the question of whether the URL contains binary versus
UTF-8 encoded string content. In particular I'm thinking about things like external biometrics
(retinal scan etc) which may be imported into the directory from files initially.

In this case the code handling the ":<" would need either:
    a) Access to the schema to know an attribute was binary, if indeed it is possible to deduce
this from the schema (excuse my ignorance). The code does not currently have this context
available to it.
    b) Some extra syntax similar to my earlier addition to denote whether binary or string
data is to be read (assuming a UTF-8 encode string is the default, then the binary case might
look like):

    # attribute is stored as byte[] 
    fileurl:< binary, file:///D:/retinal_scan/joe_blogs.dat

> Support for ":<" LDIF syntax in ApacheDS
> ----------------------------------------
>          Key: DIRSERVER-604
>          URL:
>      Project: Directory ApacheDS
>         Type: New Feature

>   Components: ldap
>  Environment: N/A
>     Reporter: Norbert Reilly
>     Assignee: Emmanuel Lecharny
>  Attachments: rfc2849 _inclusion_support.patch, rfc2849 _inclusion_support.patch, test_inclusion.ldif,
> I have need to import potentially long files via LDAP and noted that
> rfc2849 mentioned the ":<" operator allowing an attribute's value to
> be provided by "including" the contents of a URL.
> I have added the support for ":<" by enhancing
> in
> trunks/shared/ldap .

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message