On Thu, 7 May 2020 at 08:38, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > > Hi Sam, > > FWIW, I don't have much time to work on Whimsy at the moment but I'm > interested in keeping track of what's going on and help with the > design whenever that makes sense. Especially around helping make the > Board's work more asynchronous. > > If I end up writing some code, I'm more familiar with JavaScript than > Ruby but far from being an expert, I could do some small things in > both languages. > > I have one comment on the /public data that you mention. > > On Thu, May 7, 2020 at 12:58 AM Sam Ruby <ru...@intertwingly.net> wrote: > > ...Instead of having shared libraries for parsing committee-info.txt, there > > can be a canonical JSON file for this data, and multiple tools can have > > file watchers that trigger when this file changes. > > > > In fact, we already have these types of files; you can see them in > > https://whimsy.apache.org/public/. We can create some more and put them > > in a private director... > > I like this design a lot: provide a set of canonical read-only data > files that are easy to understand, with models that "never" change > (Famous Last Words) and update the files automatically when the source > data changes, providing a way to observe those changes. > > On public vs. private I suggest creating multiple private folders to > define who can read what, like private/members, private/board etc. > > It's then easy to use standard HTTP access control on those folders > and makes it very clear what's what. > > Serving that data from a specific subdomain like > data.whimsy.apache.org might help with statistics and if data use
A subdomain would need a change to DNS and probably the existing SSL certificate would not work. Not blockers, but the extra work would need to be factored in. > grows it's good to have the simplest possible thing serve it, whereas > Whimsy itself needs more machinery. > > -Bertrand
