[Design] Bridging the gap - email options

[Jared Rhine]

Jared Rhine wrote:
> I hadn't considered that model previously; I wrote about a server-centric
> model recently.  I like the "full featured"-ness that having Chandler itself
> do all the parsing of the submitted string.

I previously was talking about having an email robot do the parsing and
perform the operation.  But it's more clear that if this is a general
submission mechanism to a collection, it's really Chandler that will be
implementing the majority of the functionality.

Ok, cool, that thins out the server layer quite a bit (ignore relatively
large chunks of previous communications advocating service-layer parsing),
and the service can forward emails into a collection as fast as Cosmo can
accept them.

I just wondered though, how this interacts with multi-user collections?  If
the service adds an item to a collection, and multiple people do a
background sync and have the item in triage, what happens then?  Do both
Chandler's recognize the submission and process it, possibly adding
duplicate events into a calendar?

-- Jared