[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Enhancing back-sock to use JSON

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature