Subject: [Jmap] message vs. annotation

From: Dave Crocker <[email-masked]>
Date: Fri, 31 Mar 2017 18:23:13 -0500

G'day,

The working group meeting discussion about a static message, dynamic 
annotation, etc., resonated with a variety of similar discussions I've 
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as two 
views of the same thing.  (Ie, Document with attributes; Message with a 
body.)

The essence is to consider the nature and relationship of the objects, 
possibly permitting different semantics for the same set of objects, 
according to different applications or roles.

That is, there can be a variety of constituent objects that are 
associated and can be viewed according to different semantics (or 
views)...  So a message, a document, a calendar entry, a series of 
comments, etc.  Each object has associated processing rules (eg, static 
vs. editable vs. executable; constrained choice of values; organization 
into folders or other schemas...)

An environment like this can  be powerful and very appealing.  The 
challenge tends to be staying practical:  With no effort at all it 
devolves into an abstract computer science exercise.  Some of that is an 
efficiency issue(*) but I think it's mostly about the human 
manageability for design and operations.

Based on both the years of commercial use and the public commentary 
about the performance, I've no doubt the fastmail system does not suffer 
these downsides.  But it's a potential that this re-casting through the 
IETF could easily suffer.

I'm posting this note partly because I think it would exciting to 
produce specs that permit a degree of flexibility that such an approach 
permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic 
object types and a small number of 'relationship' types that define the 
association between objects.  These could then be combined into 
higher-order, formal organizations/semantics the define an application 
semantic (mail, calendar, whatever.)

d/

(*) A system I did in 1977 has a little bit of this and the extremely 
pure design produced impressively horrible performance.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net