On 4 December 2015 at 17:04, Sam Ruby <[email protected]> wrote: > 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.
I don't think there would be any need to use the Whimsy libraries for the LDAP stuff. My intention was purely to extract the LDAP data into a usable JSON format. No conversion of whimsy <=> whimsical etc would be done. That would be up to the applications using the data. > 2) existing Whimsy libraries similarly could not make ready use of > function provided in Python The Ruby scripts could make use of the generated JSON files, and could potentially invoke the script (as a shell command) in order to get the most recent copy. > 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
