duncanvr / arnold Goto Github PK

Seeing that I'm the only one with +/- 16 hours a day to program, I will take on me the responsibility to create the first implementation.

To stay true to the original intent of the application, I will build it using Clojure for the backend-end, Datomic as database and ClojureScript as front-end. This will ensure that the project will be completely over-engineered and never to be completed.

I leave all design-documents, documentation and architectural decisions to be written by people with actual CS degrees, and to be completely ignored by me.

Also I recommend changing the application name to the:
Clojure Language Amazing Recurrent Known Scheduled Occasion Notifier, or CLARKSON for short.

Love,
Dzjon

Let's start thinking about what ARNOLD should actually do. Below is my vision, but feel free to comment or question any assumptions I made.

The problem ARNOLD is trying to solve is to make regular meetings happen more regularly. The reason this doesn't happen right now is that with reduced availability of every member, these meetings actually started requiring planning. A mundane task that is best left to computers.

For ARNOLD to calculate the optimal meeting dates, it requires some input:

• the availability of each member;
• the minimum number of members that should be available to hold a meeting.

Because some days are more preferable than others (e.g. weekends are more suitable than week days), I suppose the availability should not be a simple boolean, but should be able to represent preference.

The availability should obviously be provided by the users through one of the clients.

Then at a set interval ARNOLD calculates the next date for a meeting and asks each member to confirm the date. If everyone accepts the date, then everything is OK and beer, stories and Arnold movies will be enjoyed. If someone rejects the date, ARNOLD calculates the next best date. If ARNOLD is incapable of calculating a date because not all criteria are met, a failure notification will be sent to each member and the meeting will be postponed to the next period.

Any suggestions, additions, etc.?

Seeing that this will be a multi-user application, I'd opt for a client-server architecture. This has the added benefit that we can write/replace both sides separately and play around with different approaches.

A simple RESTful service using JSON messages should do the trick for the server side. A client implementation could be done as a website or console application, or perhaps even a mobile app if someone is feeling generous.

Given the premise from the readme, that backwards and forwards compatibility should be part of the design criteria, I'd suggest versioning the APIs from the start. I'm not entirely sure how to best incorporate that with the statelessness of the REST principles though; any thoughts?