Hi Fredrik,
On 13/03/2025 18:53, Fredrik Roubert wrote:
On Thu 13 Mar 2025 at 01:03 +0100, Emmanuel Lécharny wrote:
There is a class that check that the syntax is correct:
org.apache.directory.api.ldap.model.schema.syntaxCheckers.PostalAddressSyntaxChecker
I'm not quite sure what you're trying to tell me with that. For this
proposal, I first looked at how the Generalized Time syntax is handled
already and for that there's functionality for checking the syntax here:
org.apache.directory.api.ldap.model.schema.syntaxCheckers.GeneralizedTimeSyntaxChecker
And functionality for decoding & encoding here:
org.apache.directory.api.util.GeneralizedTime
Indeed, but this is a very different type of object. We use the
GeneralizedTime in many places inside the API and the server, and we
need to create an instance of this class for things like checking if a
password has expired, so we need an encode and decode method for it.
We don't do that with Postal Address: the user provides it, and we
simply convey it as an attribute value to whatever needs it (ie a LDAP
server).
So the contract is that the Postal Address provided as a String by a end
user *must* be syntaxically correct, and more important, escaped if
needed, by the user, not by the API.
What I mean is that the API can't know if a '$' or a '\' are to be
escaped (there is no third char to be escaped, btw), so they must have
been escaped before being used by the API.
So to speak, an encode or decode method are pretty much not needed for a
Postal Address in the API.
Now, regarding the way Studio uses the Postal Address, it's really a
different problem: the GUI allows the user to enter an address with
*real* newlines (ie not '$'), and once the input completed, it has to be
translated to a RFC 4517 valid form (where the \n are substituted by
'$', and '$' in the input replaced by \24, same thing for \.
But this is a Studio thing, not a LDAP API thing.
OTOH, if you suggest we should let an API user provides a multi-line
String and let the API do the escaping work, instead of doing it in
Studio, I'm not against it, I wasn't thinking it would have been useful
when we first wrote the API, but thinking about it now, I can see what
you mean.
Wa can definitively add such escape/encode and unescape/decode method to
the API.
Currently, the GeneralizedTime class is in o.a.d.api.util package, but
if we are to create encoder/decoder for more schema objects, it would be
a better idea to store them into o.a.d.api.ldap.model.type (a new
package) that would store the Classes for values we may want to
encode/decode.
I hope I have been clearer than in my previous mail.
--
------------------------
Emmanuel Lécharny
emm...@worteks.com
elecha...@apache.org
------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
