RE: [Vote] Accept Scim contribution

+1 Regards, Jiajia -Original Message- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Saturday, June 25, 2016 7:45 AM To: Apache Directory Developers List Subject: [Vote] Accept Scim contribution Hi guys, two months ago, Shawn Smith wrote us to

[jira] [Commented] (DIRSTUDIO-1080) Unable to save Server-Configuration: ERR_55 Trying to remove an non-existant attribute: attributetype

[ https://issues.apache.org/jira/browse/DIRSTUDIO-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352132#comment-15352132 ] Emmanuel Lecharny commented on DIRSTUDIO-1080: -- And we have day jobs, we had to cut a

Result, was: [VOTE] Apache DS 2.0.0-M22 release

Hi, I'm closing this vote, with 4 binding +1 : Colm, Kiran, Stefan and me. I'll push teh pacages and update teh site tomorrow. Thanks, guys !

[jira] [Commented] (DIRSTUDIO-1080) Unable to save Server-Configuration: ERR_55 Trying to remove an non-existant attribute: attributetype

[ https://issues.apache.org/jira/browse/DIRSTUDIO-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15351981#comment-15351981 ] Haochen Xie commented on DIRSTUDIO-1080: Okay, if the new release is coming this week (this

Re: [Vote] Accept Scim contribution

+1. Colm. On Mon, Jun 27, 2016 at 9:57 AM, Radovan Semancik < radovan.seman...@evolveum.com> wrote: > +1, of course > > On 06/25/2016 01:44 AM, Emmanuel Lécharny wrote: > >> Hi guys, >> >> >> two months ago, Shawn Smith wrote us to inform the Apache Directory >> project that he wanted to

[jira] [Resolved] (DIRKRB-590) Adding the sasl negotiation on remote kadmin

[ https://issues.apache.org/jira/browse/DIRKRB-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiajia Li resolved DIRKRB-590. -- Resolution: Fixed commit a4040027b62f9995cfa340d953506e1305c919db Author: plusplusjiajia

[jira] [Created] (DIRKRB-590) Adding the sasl negotiation on remote kadmin

Jiajia Li created DIRKRB-590: Summary: Adding the sasl negotiation on remote kadmin Key: DIRKRB-590 URL: https://issues.apache.org/jira/browse/DIRKRB-590 Project: Directory Kerberos Issue Type:

RE: Rethinking Mavibot...

Thanks for the update. It looks like to me there is much work to do. Is there any alternative option? I'm still thinking that if we could leverage any existing back end implementation, so we could focus on the LDAP specific logic for the master server component...this is worth being considered

Re: Rethinking Mavibot...

Le 27/06/16 à 13:05, Zheng, Kai a écrit : >>> Transaction has to be started explicitely from the LDAP layer... > Yeah, I agree. But that doesn't mean the LDAP layer has to implement the > transaction support itself. It just needs to aware, start and end the > transaction when performing

Re: Rethinking Mavibot...

> On Jun 27, 2016, at 7:29 AM, Emmanuel Lécharny wrote: > > Here is what I would suggest : > > - LMDB is an obvious candidate if we want to use something that exists, > and which is proven to work. > - There are a coupld of existing bindings for LMDB : >

Re: Rethinking Mavibot...

Le 27/06/16 à 13:02, Zheng, Kai a écrit : > I really think the community need to think about this seriously because it > regards how the parent project would evolve in the long term. Lacking a > strong and solid LDAP server backend, it would shade our many efforts in > other aspects.

Re: Rethinking Mavibot...

Le 27/06/16 à 08:07, Zheng, Kai a écrit : > Thanks for the update. > > It looks like to me there is much work to do. Is there any alternative > option? I'm still thinking that if we could leverage any existing back end > implementation, so we could focus on the LDAP specific logic for the master

Re: [Vote] Accept Scim contribution

+1, of course On 06/25/2016 01:44 AM, Emmanuel Lécharny wrote: Hi guys, two months ago, Shawn Smith wrote us to inform the Apache Directory project that he wanted to contribute the project he is working on with Steve Moyer, Christopher Harm and Alex Haskell. We have discussed about this

RE: Rethinking Mavibot...

Thanks so much for the full explanation, Emmanuel. Sorry for my asking again. >> Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I >> have no idea what it would cost us in term of packaging. The packaging isn't really so much a problem. There is a nice way handling

Re: Rethinking Mavibot...

Le 27/06/16 à 12:15, Howard Chu a écrit : > Emmanuel Lécharny wrote: >> Le 27/06/16 à 08:07, Zheng, Kai a écrit : >>> Thanks for the update. >>> >>> It looks like to me there is much work to do. Is there any >>> alternative option? I'm still thinking that if we could leverage any >>> existing back

Re: Rethinking Mavibot...

Le 27/06/16 à 12:49, Zheng, Kai a écrit : > Thanks so much for the full explanation, Emmanuel. Sorry for my asking again. > >>> Otherwise, we could use LMDB, with a JNI wrapper. That is an option. But I >>> have no idea what it would cost us in term of packaging. > The packaging isn't really so

RE: Rethinking Mavibot...

I really think the community need to think about this seriously because it regards how the parent project would evolve in the long term. Lacking a strong and solid LDAP server backend, it would shade our many efforts in other aspects. Considering we're lacking of enough hands here and

RE: Rethinking Mavibot...

That's right. We have to choose a broadly supported backend and include all the supported binary packages. Basically, we could have the current Mavibot or JDBM as the fallback. We should really really get it work in the best on the most typical platforms, such as Linux, and wouldn't worry too

Re: Rethinking Mavibot...

Le 27/06/16 à 12:33, Zheng, Kai a écrit : > Yes, I agree. Is it possible to be a lightweight wrapper on top of the > plugined DB enginene, for example, we wouldn't need to support the > transaction stuffs by ourselves? No. Transaction has to be started explicitely from the LDAP layer, which

RE: Rethinking Mavibot...

Yes, I agree. Is it possible to be a lightweight wrapper on top of the plugined DB enginene, for example, we wouldn't need to support the transaction stuffs by ourselves? Is there any LDAP-centric engine already or allowing to do the mapping very directly? Regards, Kai -Original

Re: Rethinking Mavibot...

Emmanuel Lécharny wrote: Le 27/06/16 à 08:07, Zheng, Kai a écrit : Thanks for the update. It looks like to me there is much work to do. Is there any alternative option? I'm still thinking that if we could leverage any existing back end implementation, so we could focus on the LDAP specific

RE: Rethinking Mavibot...

>> Transaction has to be started explicitely from the LDAP layer... Yeah, I agree. But that doesn't mean the LDAP layer has to implement the transaction support itself. It just needs to aware, start and end the transaction when performing add/delete/update operations. -Original Message-

Re: [VOTE] Apache DS 2.0.0-M22 release

+1, tested the maven artifacts with WSS4J + CXF, built tag, verified signatures + digests on some of the release artifacts. Colm. On Sun, Jun 26, 2016 at 8:48 AM, Stefan Seelmann wrote: > +1 > > * verified checksums and signatures > * built from source with Java 8 > *

[jira] [Commented] (DIRSTUDIO-1080) Unable to save Server-Configuration: ERR_55 Trying to remove an non-existant attribute: attributetype

[ https://issues.apache.org/jira/browse/DIRSTUDIO-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15350737#comment-15350737 ] Emmanuel Lecharny commented on DIRSTUDIO-1080: -- Don't worry : we just have released