Over the past few months there’s been a use case that’s been nagging me. A few developers I’ve worked with have mentioned it in passing, but it never struck me as anything more than an annoyance. It came up again just the other day and I finally decided to dig in and see what all the fuss was about.
The question is two-fold:
- Given a conference record in the Meet API, what was the corresponding event in the Calendar API?
- Given a calendar event, what’s the corresponding conference record in the Meet API?
On the surface, it seems like these should be easy questions to answer.
Turns out, it’s not.
Togetherness
Before jumping in, why try and make these correlations in the first place?
A lot of early adopters of the Meet API are building meeting analytics for sales, events, and other verticals. In those cases, a comprehensive view of meetings is needed, and neither the Calendar API nor the Meet API alone suffices.
The Calendar API is great at addressing the essential who, what, when, where, and why questions of what *will* happen. The Meet API, on the other hand, tells us what *actually* happened and provides details like when people joined and left and recordings and transcripts that detail what was discussed.
There’s some overlap between them, but at the end of the day merging gives a much better picture than either in isolation.
A Simple Plan
Let’s start with the ideal case. There’s an event in Google Calendar with Meet enabled. It’s a single event and the meeting starts and ends on time. We have a 1:1 relationship between the event and the corresponding record created after the meeting happens.
Given the calendar event, retrieving the conference record is straight forward:
- Look up the meeting space using the meeting code on the event.
- Retrieve the conference records.
- Take the first one found.
The other way around is a little more complicated, but doable:
- Retrieve the corresponding meeting space for the conference record.
- Query the Calendar API for events approximately at the time of the record (+/- some reasonable slop).
- Find the event containing the meeting code
You might be thinking “Steve, this isn’t that hard, what could possibly go wrong?”
Everything.
While at a product level, Meet and Calendar appear well integrated, underneath the covers it’s a different story. The coupling between a calendar event and a meeting space is a very tenuous one and even more so when it comes to conference records.
People do all sorts of unexpected things. And it doesn’t help that conference records are defined as the period from when the first person joins a meeting space to when the last person leaves. Or that people can muck with Calendar in unexpected ways.
So what kind of things can people do that ruin our day? And how bad does it get?
White Rabbit
I’m not a punctual person. I know, I know. I’m just so absolutely amazing and perfect in every other way how could that possibly be?!
..Ahem…
OK, back to reality.
And reality is I’m often late. In my efforts to not appear late, I’ll sometimes join a meeting on my phone while I’m on my way to a meeting room or my desk at home. Fortunately a lot of other people I meet with are often late too, and that gives me an opportunity to switch devices before anyone notices.
Whew!
Except Meet did notice. And that brief time where I joined and then promptly left leaves a conference record which is then followed up by a new one when I rejoin.
This creates a problem for our previously simple algorithms for matching events and conference records. I now have two records that correlate to the same event and need a way to distinguish between them.
In this particular case, there are some heuristics we can use to distinguish between them and can filter the conference records to help us make the choice. We can look at things like:
- Overall duration or overlap with the event
- Number of participants
- Presence of artifacts
In other words, if we’re presented with a 28 minute meeting with 5 participants and a 2 minute one with just one person, it’s obvious what the right answer is.
Deja Vu
Unintentional conference records are one thing. But what about intentional ones? What if I need to keep coming back to the same meeting over and over and over again?
I recently had the joy (no sarcasm, I swear!) of participating in a 2 day design sprint where we were coming up with some amazing demo ideas for our next round of conferences. These were long days with a distributed team. We took breaks, had lunch, and split into breakout rooms at various points. For Calendar this was appropriately one big event. Meet saw things differently.
While we can filter and discard clearly invalid events as in the previous example, we can’t necessarily filter the conference records down to a single item in all cases. Here, each is valid and considered part of a single logical event.
Time Bandits
Recurring meetings aren’t fundamentally different from single meetings. Fortunately Calendar doesn’t allow recurring meetings any more frequently than daily, otherwise endless back-to-back meetings would really ruin our day. But I digress.
Normally we’d do the same thing for recurring meetings and ask the Calendar API to expand things so we can find the individual event instance.
So let’s imagine I’m on my weekly Wednesday morning call with a partner and at the end of the meeting they ask “Hey, can we move this to Thursday?”
Sure. I go into Calendar and move the meeting to Thursday. Calendar then asks:
And in my infinite stupidity, I select “All events”.
Yep, that’s right. It’s possible to retroactively reschedule recurring events. Thanks, Calendar. Thanks.
At the beginning I mentioned we needed a little bit of slop when searching for calendar events. Hopefully we all realized that meetings can start a little early or a little late and we need to cast a little bit of a wide net. If you’re like me, you were probably thinking +/- an hour would be plenty of time.
Ummm…. So how do we handle cases when all the previous events have shifted by an entire day? Or more?
If we’re lucky, we can ignore calendar events entirely. Conference records are created after the fact and are definitive. We know something happened at that time, even if Calendar thinks otherwise.
Oh. And it’s not only recurring events. Even single events can be retroactively rescheduled. So if we need the event data, the best approach is to watch Calendar and try to capture events before they happen.
- Set up a watch on events to capture new events and updates.
- Store the event ID <-> meeting code mapping in a separate store. For recurring events, this would be to the original event with the recurrence rules.
This gets us most of the way there. For single events it works great and allows us to directly look up the event. Recurring events mostly work, at least if we store the original event with the recurrence rules.
There’s one edge case that isn’t easily handled. For recurring events, if an individual instance has been modified to add additional details it may not be possible to find the specific instance. Tracking the schedule changes as a way to reconstruct history might work, but that opens up a new set of issues. I’d love to hear your thoughts here and see what other options might work.
Clone Wars
Remember how I was relieved that Calendar doesn’t allow back-to-back recurrences and how that would completely ruin our day?
About that…
One thing Calendar allows, though, is changing the meeting code for a meeting.
As a manager, I want to schedule a bunch of one-on-ones in a block. And since my team is all over the place and I don’t want to keep bouncing between meetings, I just set them all to the same meeting:
Now I have the luxury of joining once and hanging out while others pop in and out at their scheduled times.
But we have the opposite of our earlier problems — a single conference record that correlates to three different calendar events.
Other than telling users “don’t do that” there’s not a lot we can do here other than fail. In most cases it would be wrong to try and correlate these in a meaningful way. A careful user may toggle recordings between each segment which would generate separate artifacts. It’s possible to use the recordings and transcripts in the Meet API to distinguish between events, but the same sorts of challenges we have for conference records applies there as well.
Tread lightly here.
Everything Everywhere All at Once
To make matters worse, these aren’t mutually exclusive events.
The busy manager that I am, I’m late to my block of 1:1’s that all share the same meeting code and create a false conference record then decide to move them all to another day and retroactively apply to all past events…
Suddenly, all of space and time collapses and….well, at least it’s not my problem anymore.
In the end, it turns out that a lot of assumptions that are easy to make about how calendar events and conference records correlate simply aren’t true. It’s not the clean 1-to-1 mapping that we’d *like* it to be. It can be a messy many-to-many mapping littered with ambiguity. And there are cases I didn’t even mention like somebody flat out deleting calendar events.
Sigh.
A New Hope
While lots of things can go wrong, it doesn’t mean that they will. A best effort approach that expects the happy path works just fine, at least most of the time. These scenarios are likely to be rare or non-existent events in practice.
Code defensively and when in doubt fall back on asking the user to choose or just say “I don’t know” and move on.
And since I’ve thrown in more than enough movie titles, time for me to move on too
Top comments (1)
Great read!