When modifying entries, attribute names and values must have the same type

[Heiko-Zelt]

Hello,

I wonder, Mod is defined like this:

pub enum Mod<S: AsRef<[u8] + Eq + Hash> {
    Add(S, HashSet<S>),
    Delete(S, HashSet<S>),
    Replace(S, HashSet)<S>),
    Increment(S, S),
}

So when modifying entries, attribute names and attribute values must have the same type, String or Vec<u8> for example or whatever implements the AsRef-trait.

That's strange, because as far as I know and as described in RfC 2849 attribute names are always ASCII strings, and attribute values can be text or binary. For example "jpegPhoto" has an ASCII name but binary content.

Is there a reason for this? I would prefer to provide attribute names always as Strings, so I don't have to convert them into the type of my values.

Regards Heiko

[inejge]

So when modifying entries, attribute names and attribute values must have the same type[...] Is there a reason for this? I would prefer to provide attribute names always as Strings

The reason is twofold:

1. In my experience, attributes in LDAP client applications are predominantly String-valued. Binary attributes are a comparative rarity. Cursory reading of others' LDAP code has confirmed that view throughout the time I've been working with LDAP.
2. Proliferation of generic parameters in Rust can lead to rather convoluted code, so I prefer to have as few as possible.

Effectively, I'm at peace with making the lives of those who have to handle binary attributes (including myself) a bit more difficult in order for others to have less hassle. The (very) long-term plan is to implement some kind of automatic (de)serialization which would avoid the necessity of coercing data references to the widest required type. As for Mod, I have no plans to work on changing it, but I might be persuaded by a fully backwards-compatible PR.

[Heiko-Zelt]

I am writing a daemon to synchronize subtrees of LDAP servers. Reading binary data is easy, but modifying is more complicated. For now I have only found binary data in test data in our development environment, not in production. Now I am writing a warning message to the log file instead of synchronizing it. And I also added a warning to my README, so it's documented that binary data is not synchronized.

[inejge]

For an illustration of binary value update handling, see #35.