On Fri, Dec 4, 2015 at 11:02 AM, sebb <[email protected]> wrote: > On 4 December 2015 at 12:49, Sam Ruby <[email protected]> wrote: >> On Fri, Dec 4, 2015 at 5:24 AM, sebb <[email protected]> wrote: >>> The JSON files already in the public directory are now usable by >>> Javascript and other apps. >>> >>> It occurs to me that there are other data sets that would be useful as >>> JSON files. >>> >>> For example: >>> >>> LDAP extracts: >>> - listing of committee names (as per list_committee.pl) >>> - listings of committee members (list_committee.pl *) >>> - listing of unix groups (list_unix_group.pl) >>> - listings of unix group members (list_unix_group.pl *) >>> - listing of PMC chairs >>> - listing of people - at least cn, pgp Key. ssh Key. isEnabled (i.e. >>> valid shell) >>> >>> asf-authorisation-template extract: >>> - listing of locally defined groups (mainly podlings) >>> >>> Some of the above would also be useful as combined files, e.g. the >>> committee names and members; ditto for unix groups. But for apps that >>> don't necessarily display all the group membership details at once it >>> would be useful to have them as separate files as well to reduce the >>> download sizes. >>> >>> Some of this information is potentially available from projects.a.o >>> (though in different combinations). >>> >>> It occurs to me it might be better to standardise on the whimsy public >>> area, rather than having multiple sources in different formats. >>> >>> Thoughts? >> >> I very much like the idea of (a) a single source of truth, that is (b) >> human readable. There are too many exceptions (example >> whimsy=>whimsical) that can trip up various tools; having each tool >> ultimately using the same source, and having the intermediate results >> being inspectable is a Very Good Thing. Bugs will be found earlier, >> and fixes will accrue benefits everywhere. >> >> If you work in this area, I will review, contribute, deploy, and help >> maintain the results. Over time (once we have a canonical repository >> and the new VM is set up with pubsub or equivalent) you and others on >> this project will also be able to deploy. My biggest concern is that >> I don't want to continue in the mode where I develop tools that others >> find useful where I'm the sole maintainer of the results. > > Understood. > > Do you have any objections to adding code written in Python?
Not an objection, but... > I ask this because Python supports automatic LDAP server failover > (which it appears the Ruby gem does not) and I have already got some > sample Python code. ... some disjoint observations: 1) such could could not readily make use of existing Whimsy libraries I've build up to handle various things potentially leading to duplication. 2) existing Whimsy libraries similarly could not make ready use of function provided in Python 3) server failover sounds like a desirable feature, one that would be handy to make use of in whimsy libraries. While not built into the LDAP library, it appears to be provided elsewhere: https://github.com/ruby-ldap/ruby-net-ldap#extensions https://github.com/javanthropus/resolv-srv - - - Given the above, if you feel you wish to continue with Python, I don't object. Alternately, if you would like help with converting code (I'm fluent in both Python and Ruby) or recommendations on changes on how the existing Ruby Whimsy code uses LDAP, I'm willing to participate in that too. >> - Sam Ruby
