I’ve been reading Lance Halvorsen’s new beta book “Functional Web Development with Elixir, OTP and Phoenix” and it’s got me thinking about new ways of using processes.
In the book, you build a battleship-clone, and the gameboard you build is built with coordinates - each of which is its own process. The advantage you get out of this is that each coordinate is independent yet can hold it’s own state, and also a coordinate exists independent of any sort of heirarchy. Since it is just a process, it can be a part of different branches of data and easily read / updated.
I was wondering if it would be possible to do the same sort of thing with a calendar app. Each date could be a process that stores the events/times happening that day, one advantage being that you could potentially check for room conflicts when creating a new weekly event that just calls up the processes associated with the dates you are scheduling to check for any potential conflicts.
Obviously, one huge issue with this thought process is timezones - so maybe it’s an entirely wrong-headed approach.
My work currently has several calendar apps built in Rails and finding/resolving conflicts is one of the biggest sluggishness factors - so that is definitely one factor that I’m trying to find a solution for.
Just sort of spinning this stuff around in my head and wondering if anyone has any thoughts or ideas for a way to take advantage of OTP in a scheduling/calendar app.
Heh, actually I have no idea - I’m actually not super familiar with Rails.
Honestly, I’m more focused on “how to think about a scheduling calendar within OTP” than specifically fixing problems with the Rails app, though that is what sort of sparked this.
Now regarding this OTP app idea of yours. What kind of granularity would the processes have? I can’t think of a level of granularity that would actually work for this example, hence why I ask. You couldn’t have a process per hour because then what if an event spans multiple hours? You can scale that idea up to days, weeks and months.
I see you suggested days, but what about an event that spans over two days?
I am not entirely sure that an OTP app here would work, but I am not an OTP expert by any stretch of anyone’s imagination. I’m open to being proven wrong here.
What if each future event is a process? To check for conflict, send a message to all events, those with conflict will report back, you can then cancel event that are not prioritized.
To infinity and beyond Recurring events will implement conflict check differently and only one process exists, one-off event is one process. I think this design makes sense if you want to do something fancy like weighted job scheduling which is a pretty classic problem.
Groups and registers ! Each event is an independant process. You register them to a group/register for the room. And when a new event come, you can just broadcast to all event asking for conflicts. They are optimisations that can be done, like also having a “leader” process per room that handle an aggregated copy of the data, etc etc.
I think @Trevoke is discovering that lately through his side project.
Having every event an independent process does offer significantly more freedom overall, although it does mean a change in perspective and tooling.
It turns out Google Calendar’s current interface can show you some reasonable approaches to it, by limiting the time range in which it will suggest times for the meeting: if you’re concerned about every event ever being a process, you can also just spawn the ones you’re likely to need.
Yeah, I think I realized pretty quickly that some sort of process-per-date wasn’t really going to work out.
Having a process per future event sounds like a pretty good direction though.
Our current older calendar does a daily job that assures all recurrence patterns are run/up-to-date as far out as 2 years. It would be great if this wasn’t a limitation, but I’m not sure how to go about it. Possibly future dates from a recurring event could be auto-generated from a recurrence pattern definition on a per-room level only when checking that room for conflicts? I still have to figure out how to define that recurrence pattern too.
Is there a way to define a datetime range (i.e. May 3rd, 1pm-3pm) in a single datatype or is just defining a start-datetime and end-datetime the best way to go about that?
I like the idea of each room having its own leader process that knows all of the events it exists in. I’ll have to take a look at Trevoke’s project to try and wrap my brain around it more.
Recurring events will implement conflict check differently and only one process exists, one-off event is one process. I think this design makes sense if you want to do something fancy like weighted job scheduling which is a pretty classic problem.
