On 4 févr. 2012, at 01:52, Alex Karasulu wrote:
On Sat, Feb 4, 2012 at 2:47 AM, Emmanuel Lecharny elecha...@gmail.com wrote:
On 2/3/12 11:09 PM, Alex Karasulu wrote:
On Fri, Feb 3, 2012 at 12:59 AM,elecha...@apache.org wrote:
Author: elecharny
Date: Thu Feb 2 22:59:08 2012
New
[
https://issues.apache.org/jira/browse/DIRSTUDIO-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201154#comment-13201154
]
Pierre-Arnaud Marcelot commented on DIRSTUDIO-765:
--
Thanks for the
May be we are looking at the problem from the wrong side.
All in all, is the user interested into the class used to load the
schema ? What about telling the SchemaManager to load the schema, and
telling it to use a schemaLoader of our choice if needed ?
As of today, we do :
I agree these names may not be very obvious for the casual user.
My personal preference would go to:
- DefaultNetworkSchemaLoader
- ApacheDsNetworkSchemaLoader (I find it more explicit than with 'Ads' as this
class will be in the API and people may not be very familiar with the 'Ads'
prefix, no
On Mon, Feb 6, 2012 at 2:27 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
May be we are looking at the problem from the wrong side.
All in all, is the user interested into the class used to load the schema ?
What about telling the SchemaManager to load the schema, and telling it to
use a
I really like the idea too, but I think we can combine both approaches.
I see the SchemaManager more of an internal class and not something that
someone (except experts) would instantiate.
To ease the loading of the Schema and make the API schema aware, avoiding
issues with binary attributes
On 2/6/12 10:20 AM, Pierre-Arnaud Marcelot wrote:
I really like the idea too, but I think we can combine both approaches.
I see the SchemaManager more of an internal class and not something that
someone (except experts) would instantiate.
Agreed.
To ease the loading of the Schema and make
Hi guys,
last week, we have had issues on Studio while using the API to load
JpegPhoto attributes. As the JpegPhoto was not known to be a Binary
value, it was converted to a String, leading to some internal
transformation of the data. Not good.
So we discussed about adding a list of known
So let me summarize many aspects we have discussed about the schema
handling in the API in this mail.
From the API POV, we should distinguish four cases :
- we don't want to load any schema
- we want to load a schema from a LDAP server
- we want to load a local schema (ie, from some files)
On 6 févr. 2012, at 15:11, Emmanuel Lecharny wrote:
So let me summarize many aspects we have discussed about the schema handling
in the API in this mail.
From the API POV, we should distinguish four cases :
- we don't want to load any schema
- we want to load a schema from a LDAP server
I believe we need this list only in the case where no schema is loaded on the
connection, right?
Or, do you want to also use this list in addition to an already loaded schema?
Regards,
Pierre-Arnaud
On 6 févr. 2012, at 14:04, Emmanuel Lecharny wrote:
Hi guys,
last week, we have had issues
On 2/6/12 4:11 PM, Pierre-Arnaud Marcelot wrote:
I believe we need this list only in the case where no schema is loaded on the
connection, right?
Sadly, no. For servers that don't expose the information about the non
human readable Syntax, we have to provide it. We use a
X-IS-HUMAN-READABLE
On Mon, Feb 6, 2012 at 5:58 PM, Emmanuel Lécharny elecha...@apache.orgwrote:
On 2/6/12 4:11 PM, Pierre-Arnaud Marcelot wrote:
I believe we need this list only in the case where no schema is loaded on
the connection, right?
Sadly, no. For servers that don't expose the information about the
After some talk with Emmanuel, we think we would still need to have a list of
binary attributes, in addition to the list of syntaxes which also makes sense.
There are three use-cases:
1°/ The schema is not loaded = We filter binary values using the binary
attributes list.
2°/ The schema is
14 matches
Mail list logo
