You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by sebb <se...@gmail.com> on 2017/06/03 14:16:53 UTC

How should LDAP project group data be published?

The script public_ldap_projects.rb is available for creating JSON
listings of the new ou=project LDAP groups, but it has not yet been
deployed as a cron job.

The strategy so far has been to publish the raw LDAP data in JSON form.

However this means that changes to the LDAP schema tend to affect all
consumers of the JSON files. For example, at some point the files
public_ldap_committees.json and public_ldap_groups.json will
presumably be dropped, as the corresponding LDAP groups will have been
replaced by the project groups.

Maybe there should be both raw JSON files which correspond to
individual LDAP groups, as at present, as well as some other JSON
files which contain 'interpreted' data?

If these 'interpreted' data files are suitably designed, this should
avoid the need for applications to be updated if/when LDAP - or other
raw data - changes.

WDYT?

Re: How should LDAP project group data be published?

Posted by sebb <se...@gmail.com>.
The raw data is now being published .

See separate thread about how to handle the transition in public data files.

On 3 June 2017 at 15:16, sebb <se...@gmail.com> wrote:
> The script public_ldap_projects.rb is available for creating JSON
> listings of the new ou=project LDAP groups, but it has not yet been
> deployed as a cron job.
>
> The strategy so far has been to publish the raw LDAP data in JSON form.
>
> However this means that changes to the LDAP schema tend to affect all
> consumers of the JSON files. For example, at some point the files
> public_ldap_committees.json and public_ldap_groups.json will
> presumably be dropped, as the corresponding LDAP groups will have been
> replaced by the project groups.
>
> Maybe there should be both raw JSON files which correspond to
> individual LDAP groups, as at present, as well as some other JSON
> files which contain 'interpreted' data?
>
> If these 'interpreted' data files are suitably designed, this should
> avoid the need for applications to be updated if/when LDAP - or other
> raw data - changes.
>
> WDYT?