On 15 February 2016 at 16:31, Sam Ruby <[email protected]> wrote: > On Sun, Feb 14, 2016 at 11:03 AM, sebb <[email protected]> wrote: >> The people public data currently only includes id, name, and noLogin >> (disabled login) status. >> >> This is adequate for most purposes, however there are use cases for >> additional info. >> >> For example, reporter.a.o needs the creation date (to show committer >> number changes) >> >> One could add the information to the existing data file, but this >> would increase the file size. >> This would increase resource usage unnecessarily for most cases. >> >> I'm therefore thinking it would be useful to provide a second version >> with more info. >> This could be generated by the same cronjob - it would just create an >> additional file. > > Just a guess, but reporter.apache.org only needs to know the dates for > people who have been added in the last 90 or so days?
Sorry, I remembered incorrectly. It seems it is projects.a.o which needs them to create accounts-evolution.json It needs the data for the current month and for the previous month on the first of the month. So it would be possible to limit the number of extra attributes if desired. [And its LDAP query could probably be filtered to eliminate the unneeded data at the server] >> The alternative is for apps to continue to use LDAP directly for such info. > > How is that a problem? Trickier to code. Takes longer to run. If needed for a web app, the browser cannot cache the data. Extra load on LDAP. >> Thoughts? > > Generally, I'm opposed to premature optimization. And to building > something that a tool might need. Though once one has the data in an easily consumable format, that may encourage people to generate useful tools from it ... > If the reporter tool is run a few dozen times a month, and is only The cron jobs run at least every night for both projects and reporter. I don't know how often people access the GUI pages that consume the json data. > looking at three months of data, extracting a complete list of every > person and their creation date every 15 minutes seems like overkill. > A cgi script that returns on demand a more customized result might be > a better fit. Yes, I had wondered about that. > - Sam Ruby
