Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

What every part shares

The parts share everything but the service. eddy writes four things once, and every part calls them: the key’s shape, the meeting’s details, the raw layout, and the rule that skips a meeting too short to hold anything. A part’s own code reads its service in the service’s terms and hands the shared code one shape of meeting. The raw layout has a chapter of its own, A meeting’s raw files.

The key

A part keys a meeting by its service and the meeting’s own id:

meeting/<service>/<meeting id>

<service> is the part’s name, such as wispr, and <meeting id> is the id the service gives the meeting. The key is the meeting’s identity: every host and every run gives one meeting one key, and millpond holds one capture per key (111). Every meeting key starts with meeting, so none starts with /, captures or moves, which the contract refuses (the key).

The key is what lets a part forget. millpond looks every key up in the inbox before it writes, so a part keeps no list of what it reported and may list the same window as often as it likes. What a key cannot do is join two services: a meeting recorded on two services gets a key from each, and two captures.

One key per meeting per service On the left, a part runs at 09:00 and lists meetings m41 and m42, then runs at 12:00 and lists m42 and m43. millpond writes three captures; the second line for m42 is passed over and counted. On the right, one meeting recorded on Wispr Flow and on Webex gets two keys, meeting/wispr/a7f and meeting/webex/9921, and two unread captures. A reader reads them together and writes the second's signals once. ONE MEETING LISTED TWICE run, 09:00 meeting/wispr/m41 meeting/wispr/m42 run, 12:00 meeting/wispr/m42 meeting/wispr/m43 millpond three captures; m42's second line is passed over and counted One meeting has one key on every host and in every run, so a part lists any window again and keeps no list of what it reported. ONE MEETING RECORDED TWICE One meeting recorded on Wispr Flow and on Webex meeting/wispr/a7f meeting/webex/9921 Two captures, both unread A reader reads them together and writes the second's signals once
The key is a meeting's identity on its service. A window listed twice gives each meeting one capture. A meeting recorded on two services gets two keys and two captures; eddy cannot know they are one meeting, and its reader joins them.

A meeting recorded twice is the reader’s to join, because only a reading tells that two transcripts hold one conversation. The reader reads the two captures together and writes the second’s signals once (millpond’s reader).

The meeting’s details

Every part reads four details of a meeting from its service and hands them to the shared code in one shape:

DetailBecomes
titlethe capture’s title, the one line a person reads in a list
startthe capture’s event_at, in RFC 3339
lengththe input to the skip, below
attendeespart of the meeting’s record; the contract gives them no field, and Open questions holds where they travel

When the meeting started

A meeting capture’s event_at is when the meeting started, never when a part listed it or millpond captured it, because weight counts by event date (118). A meeting a part lists a week late counts from the day it was held, so a backlog reaches curation in the order its meetings happened.

Skipping a short meeting

A part prints no capture for a meeting too short to hold anything. The meeting’s length decides the skip, so every run and every host skips the same meetings, and a skip needs no record. Where the line falls is open.