Given the swingeing criteria in my first post, I decided to start by creating the simplest interface I could.
I began with a simple database of Perches in a spreadsheet and then in the Script Editor created a rough GUI with a couple of dropdown menus, and a couple of buttons that I would fill with data from the a mixture of a Perches calendar and this spreadsheet.
I decided not to keep track of bookings in a separate spreadsheet, simply because this felt like it would just be a whole heap of work. I would just use a calendar to store bookings. The guest of each event would decide who's booking it was.
There are two areas of the interface, in the top bit, you can pick a date and book it ( it shows how many perches there are left ). In the bottom bit the dropdown menu is a list of dates you have booked and you can delete them. Like this...
The green blob at the bottom is just where I splat debug stuff. The list of perches is kept in spreadsheet called "Perches" and availability is worked out by simply counting the number of events on a particular day and taking that away from the number of perches. Rocket science.
I thought having LOADS of events in a calendar might look very crap but, it seems to cope.
And in Agenda View it worked even better.
And because the user is "added a guest", it magically appears in their calendar like this shown below, with an email reminder if I want.
Note: Declining the invitation doesn't delete the original event from the calendar ( but, if done from the interface could ).
How I Did It
... and this called ...
... and the method that is called when the button is clicked...
So there we have it. Nowhere near finished but working well enough to prove that, given very simple restraints, something simple is feasible.
Is it me or is working with All Day Events a bit buggy? They almost always end up on the wrong day. I'm doing something wrong.
The interface needs a "loading" animation or something when the button is clicked ( it takes about 4 seconds and nothing happens. People will just double book ). I've got a suspicion I don't need to send the rootComponent up and down onClick... I get the feeling I need to understand the mechanics of what is going on underneath the a mouseClick just to make it a bit snappier.
I found a "Known issue" which goes along the lines of "Google value your data integrity more than anything else in world, so were quite happy giving you spurious error messages that are essentially lies as long as your data isn't corrupted. Great. It happens when I try to add to many items at once to the calendar and a lock happens ( I think )... Google reports it's a "mismatch of keys"....
Oh, and this is a handy error screen too. Great. Thanks again Google.
And of course, the fact that the requirements I started with are all wrong in that the were necessarily restricted. This is definitely one of those problems that you are trying to match the tools to the solution. If the solution can be kept "simple enough" then it can be done quickly and perhaps evolved.
Sometimes quirks, like only being able to see two weeks into the future... an accident of working around something ... could actually be recast as a feature, making the end user less likely to block book, making the availability of perches more equitable. Ahem.