[Chandler-dev] Edit/update (email sharing) model thoughts

[Brian Kirsch]

On Dec 8, 2006, at 12:12 PM, Phillip J. Eby wrote:

> At 11:02 AM 12/8/2006 -1000, Brian Kirsch wrote:
>> To prevent this I propose that each Chandler instance should have a
>> unique application level UUID. This UUID would be included as the
>> mail header X-Chandler-ID.
>> When a message is received if the sender is the same Chandler (the  
>> X- Chandler-ID matches) then ignore the message. This works nicely  
>> since
>> one of the proposals
>> for Preview is to have an option where Chandler only downloads mail
>> from an IMAP or POP server that is sent from another Chandler. For
>> this case, we can leverage
>>  the X-Chandler-ID as the key to determining if the message is from
>> Chandler. Thus allowing users to continue working with traditional
>> email clients while
>> leveraging Chandler for intercommunication as is the case with the
>> Edit / Update workflows.
>
> Just FYI, but the protocol we've defined doesn't actually need  
> this, in that receiving an already-applied update is a silent no- 
> op.  Having this header would allow us to skip some steps, but it's  
> not strictly necessary.

Yes it is true that I could just pass the notification data EIM  
message to the sharing layer. I was just trying to limit the amount  
of redundant steps. Since the information contained in the email will  
match the
item at the time of sending. Using a unique ID seemed a way to avoid  
having to burden the sharing layer. I could also use messsage id's  
instead of a X-CHANDLER-ID. For example, store the
message id's of notifications from myself so when one comes back in  
to Chandler I know to ignore it.



>
> Note also that there are privacy issues involved in having a UUID  
> that gets carried in all communications.  I would also suggest that  
> if we do this for sharing purposes, it should be a different and  
> *secure* UUID (i.e., one not generated using the Ethernet hardware  
> address) for each effective sharing conduit, to minimize the amount  
> of trackable information being distributed about the person's machine.

+1 the UUID would just be a random id and have no ties to the users  
hardware or software. But again the UUID suggestion could be changed.  
There are many ways to track that I sent this message so ignore it.

>

-Brian