gistfile1.go

package event

// Events returns the set of events describing the change from prev -> next
//
// This is a fairly complex operation, and needs to handle the following
// edge cases:
// * A message could be copied from one folder to another, which we can only
//	 determine based on message ID (which isn't present in the snapshots)
// * A message coule be moved from one folder to another, which also relies on
//   message ID
// * A modified message might not have been processed by the initial sync, in
//	 which case it will only have a 'Quick' ID.  In this case we need to emit
//   both a 'MessageCreated' event based on the previous state and a
//   `MessageModified` event based on both prev & next.
// * A message's 'Quick' ID could be shared with another message whose 'Full' ID
//   is different.
// * A copied message's original location could only have a 'Quick' ID present
//
func (b IncrementalEventBuilder) Events() ([]interface{}, error) {
	// 1. Find locations that changed between previous & next

	// 2. Find existing message ID's for changed loctions
	// NOTE: This may return locations not present from (1), for messages which
	// were copied.
	// NOTE: Messages moved/copied before the initial sync processed their initial
	// location will have no ID, but we can assume their previous location has
	// a Quick ID.  The relationship between prev/next locations will be
	// discovered when we generate Message ID's later.

	// 4. If the account has Quick ID's, generate Quick ID's for locations missing
	// from (2).
	// NOTE: This is caused by messages copied/moved before their initial location
	// was processed by the initial sync.  We can only find the previous state
	// of these messages using the Quick ID, so we have to build both the Quick
	// version and the full version (later).  If the account has no Quick ID's,
	// we can assume messages with no ID are new arrivals, copies or moves from
	// locations with full ID's (in which case we can find their previous state
	// from the full ID which we'll generate later).

	// 4. Find previous locations for Quick ID's generated in (4).

	// 5. Generate message ID's and `MessageCreated` events for messages with
	// NOTE: Becase we fetched matching Quick ID's in (4), we can assume that
	// the original state is known.

	// 6. Persist message ID's for previous & current states of messages from (5).
	// NOTE: The presence of a message ID indicates that a location's initial
	// sync has completed, so it's important to avoid setting this value if
	// the 'MessageCreated' event hasn't actually been issued.
	// TODO: How do we avoid losing data if the message ID is persisted but
	// the resulting event isn't written out?

	// 7. Generate message ID's for locations with missing ID's (cache bodies)
	// Persist message ID's for current state.
	// NOTE: Missing ID's are the result of new arrivals, copies, or moves.
	// NOTE: We should only need full bodies for messages with no Message ID,
	// so this step should fully populate message bodies for `MessageCreated`
	// events.
	// NOTE: We can persist these values as they're generated because we don't
	// need to worry about doing an initial sync on the location.

	// 8. Find prevous states for message ID's generated in (7)
	// NOTE: Copied messages will not be present in the set from (2) becasue
	// no message ID has been persisted for the 'new' location, however their
	// previous location should be associated with the generated message ID.

	// 8. Iterate through folders and generate events

	// 9. Iterate through message ID's and generate events

}