Hi,
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations. The function signatures of the JSON-RPC calls are modeled to be similar to the ones used in json2ldap (which does just the opposite direction to talk LDAP via JSON-RPC) [1]. The previous hand-crafted format passed on the socket was harder to parse and needed a manually built parser whereas now a standard library can be used. However, handling the JSON data structures now imposes an additional dependency to Jansson (a JSON access library in C) [2]. Jansson itself is leightweight and has no dependencies itself. Due to the limited use of back-sock and the enhanced ease of use I think it would be acceptable to add this dependency.
I would be glad if the modification would be possible to be applied to OpenLDAP and I happily submit a patch.
Best regards
-- Dago
[1] JSON2LDAP interface from JSON-RPC to LDAP http://connect2id.com/products/json2ldap/web-api#ldap-compare
[2] Jansson, a C library for reading and writing JSON data structures http://www.digip.org/jansson/
Dagobert Michelsen wrote:
Hi,
Hi
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations. The function signatures of the JSON-RPC calls are modeled to be similar to the ones used in json2ldap (which does just the opposite direction to talk LDAP via JSON-RPC) [1]. The previous hand-crafted format passed on the socket was harder to parse and needed a manually built parser whereas now a standard library can be used. However, handling the JSON data structures now imposes an additional dependency to Jansson (a JSON access library in C) [2]. Jansson itself is leightweight and has no dependencies itself. Due to the limited use of back-sock and the enhanced ease of use I think it would be acceptable to add this dependency.
I would be glad if the modification would be possible to be applied to OpenLDAP and I happily submit a patch.
Best regards
-- Dago
[1] JSON2LDAP interface from JSON-RPC to LDAP http://connect2id.com/products/json2ldap/web-api#ldap-compare
[2] Jansson, a C library for reading and writing JSON data structures http://www.digip.org/jansson/
Hi Dago,
So would the use case for this be to talk to a JSON database like MongoDB via the LDAP protocol?
Thanks! Conrad
On Thu, 2015-02-19 at 11:41 +0100, Dagobert Michelsen wrote:
Hi,
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations. The function signatures of the JSON-RPC calls are modeled to be similar to the ones used in json2ldap (which does just the opposite direction to talk LDAP via JSON-RPC) [1]. The previous hand-crafted format passed on the socket was harder to parse and needed a manually built parser whereas now a standard library can be used. However, handling the JSON data structures now imposes an additional dependency to Jansson (a JSON access library in C) [2]. Jansson itself is leightweight and has no dependencies itself. Due to the limited use of back-sock and the enhanced ease of use I think it would be acceptable to add this dependency.
I would be glad if the modification would be possible to be applied to OpenLDAP and I happily submit a patch.
Best regards
-- Dago
[1] JSON2LDAP interface from JSON-RPC to LDAP http://connect2id.com/products/json2ldap/web-api#ldap-compare
[2] Jansson, a C library for reading and writing JSON data structures http://www.digip.org/jansson/
Hi Conrad,
Am 19.02.2015 um 18:29 schrieb Conrad Steenberg conrad.steenberg@gmail.com:
So would the use case for this be to talk to a JSON database like MongoDB via the LDAP protocol?
Not directly. I didn’t change the transport from back-sock which is still a local socket. You can now write a simple JSON-RPC server taking method calls send from OpenLDAP according to the incoming native LDAP requests. The implementation is connection-aware via cookies and multithreaded. This allows to glue on legacy data systems easily in any language that understands JSON-RPC. Of course you could also write a translator to MongoDB. In the future it may be enhanced to use a real HTTPS connection.
Best regards
— Dago
Hi Howard,
Am 19.02.2015 um 18:05 schrieb Howard Chu hyc@symas.com:
Dagobert Michelsen wrote:
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations. The function signatures of the JSON-RPC calls are modeled to be similar to the ones used in json2ldap (which does just the opposite direction to talk LDAP via JSON-RPC) [1]. The previous hand-crafted format passed on the socket was harder to parse and needed a manually built parser whereas now a standard library can be used. However, handling the JSON data structures now imposes an additional dependency to Jansson (a JSON access library in C) [2]. Jansson itself is leightweight and has no dependencies itself. Due to the limited use of back-sock and the enhanced ease of use I think it would be acceptable to add this dependency.
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
Well, of course you are right that the LDAP presentation is more efficient. However I think from a client perspective it would be easier not to deal with LDIF, especially as you can choose a JSON-RPC server suitable for your needs and have the data already available for the function and concentrate on implementing the functionality: https://en.wikipedia.org/wiki/JSON-RPC#Implementations
I see back-sock not as a solution for super high performance, but as a tool to build somewhat exotic adapters and proof of concepts. Allowing a quick implementation is at least for me the primary goal here.
Best regards
— Dago
Dagobert Michelsen wrote:
Am 19.02.2015 um 18:05 schrieb Howard Chu hyc@symas.com:
Dagobert Michelsen wrote:
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations.
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
Well, of course you are right that the LDAP presentation is more efficient. However I think from a client perspective it would be easier not to deal with LDIF, especially as you can choose a JSON-RPC server suitable for your needs and have the data already available for the function and concentrate on implementing the functionality: https://en.wikipedia.org/wiki/JSON-RPC#Implementations
You assume that many people want to do JSON-RPC. IMHO that's only your specific need. And it shouldn't be too hard for you to write an external generic back-sock listener which translates this custom LDIF to JSON and provide it as separate open source project.
The point with choosing a data format is that there are so many formats. During the last 15 years there were various major formats en vogue also with lots of proprietary flavors. I'm pretty sure JSON is not the last one, e.g. personally I lost interest in JSON-SCIM pretty quickly.
Ciao, Michael.
Hi Michael,
Am 08.03.2015 um 10:18 schrieb Michael Ströder michael@stroeder.com:
Dagobert Michelsen wrote:
Am 19.02.2015 um 18:05 schrieb Howard Chu hyc@symas.com:
Dagobert Michelsen wrote:
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations.
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
Well, of course you are right that the LDAP presentation is more efficient. However I think from a client perspective it would be easier not to deal with LDIF, especially as you can choose a JSON-RPC server suitable for your needs and have the data already available for the function and concentrate on implementing the functionality: https://en.wikipedia.org/wiki/JSON-RPC#Implementations
You assume that many people want to do JSON-RPC. IMHO that's only your specific need. And it shouldn't be too hard for you to write an external generic back-sock listener which translates this custom LDIF to JSON and provide it as separate open source project.
I would happily do that, however I need some extra fields to be passed. Without a standardized extendable format that doesn’t break existing clients this inconveniences existing users, be it XML or JSON or YAML or whatever else that doesn’t require a custom parser.
The point with choosing a data format is that there are so many formats. During the last 15 years there were various major formats en vogue also with lots of proprietary flavors. I'm pretty sure JSON is not the last one, e.g. personally I lost interest in JSON-SCIM pretty quickly.
Certainly not, but sticking to a hardly extendable custom format doesn’t seem very useful either.
Best regards
— Dago
Dagobert Michelsen wrote:
Hi Michael,
Am 08.03.2015 um 10:18 schrieb Michael Ströder michael@stroeder.com:
Dagobert Michelsen wrote:
Am 19.02.2015 um 18:05 schrieb Howard Chu hyc@symas.com:
Dagobert Michelsen wrote:
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations.
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
Well, of course you are right that the LDAP presentation is more efficient. However I think from a client perspective it would be easier not to deal with LDIF, especially as you can choose a JSON-RPC server suitable for your needs and have the data already available for the function and concentrate on implementing the functionality: https://en.wikipedia.org/wiki/JSON-RPC#Implementations
You assume that many people want to do JSON-RPC. IMHO that's only your specific need. And it shouldn't be too hard for you to write an external generic back-sock listener which translates this custom LDIF to JSON and provide it as separate open source project.
I would happily do that, however I need some extra fields to be passed.
It seems we're getting to the interesting part.
I'd also like to see back-sock used as overlay to pipe requests and responses through an external process. E.g. I'd like to rewrite filters based on authz-DN or similar but let slapd itself process the (modified) request.
Ciao, Michael.
Michael Ströder wrote:
Dagobert Michelsen wrote:
Hi Michael,
Am 08.03.2015 um 10:18 schrieb Michael Ströder michael@stroeder.com:
Dagobert Michelsen wrote:
Am 19.02.2015 um 18:05 schrieb Howard Chu hyc@symas.com:
Dagobert Michelsen wrote:
I have made some enhancements to back-sock to use JSON for the passed data and JSON-RPC to map LDAP calls to method invocations.
my initial reaction: the current format is just a tweaked LDIF. LDIF itself is still a more compact format than JSON. I personally am opposed to adding any JSON dependencies to our code base. Anyone else have an opinion?
Well, of course you are right that the LDAP presentation is more efficient. However I think from a client perspective it would be easier not to deal with LDIF, especially as you can choose a JSON-RPC server suitable for your needs and have the data already available for the function and concentrate on implementing the functionality: https://en.wikipedia.org/wiki/JSON-RPC#Implementations
You assume that many people want to do JSON-RPC. IMHO that's only your specific need. And it shouldn't be too hard for you to write an external generic back-sock listener which translates this custom LDIF to JSON and provide it as separate open source project.
I would happily do that, however I need some extra fields to be passed.
It seems we're getting to the interesting part.
Indeed.
I'd also like to see back-sock used as overlay to pipe requests and responses through an external process.
It already works as an overlay.
E.g. I'd like to rewrite filters based on authz-DN or similar but let slapd itself process the (modified) request.
Sounds like you two could start enumerating all of the parameters you would like to see added for each operation type. A final list should be submitted to the ITS as an enhancement request. Patches adding such params would be even better.
-
Conrad Steenberg -
Dagobert Michelsen -
Howard Chu -
Michael Ströder