36
edits
SoC:RoamingSupport: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
This service would also handle the dispatching of update messages. Ideally, another class would handle the gory details for message creation and maintenance of the delta messages and the full sync message. | This service would also handle the dispatching of update messages. Ideally, another class would handle the gory details for message creation and maintenance of the delta messages and the full sync message. | ||
=== Delta Update Messages === | === Delta Update Messages === | ||
The idea of storage on either the IMAP or POP3 level involves the use of a complete sync message, and corresponding delta messages for each update since the last complete sync message. | The idea of storage on either the IMAP or POP3 level involves the use of a complete sync message, and corresponding delta messages for each update since the last complete sync message. | ||
We would like to store these messages somewhere other than the INBOX, and would like to avoid the end-user discovering these messages as much as possible. To hide these update messages in the IMAP implementation, we would probably take advantage of an un-subscribed folder. For the POP3 version, we would set some sinks in the POP3 protocol implementation to process our update message, and leave them out of the users inbox. | We would like to store these messages somewhere other than the INBOX, and would like to avoid the end-user discovering these messages as much as possible. To hide these update messages in the IMAP implementation, we would probably take advantage of an un-subscribed folder. For the POP3 version, we would set some sinks in the POP3 protocol implementation to process our update message, and leave them out of the users inbox. | ||
To prevent any confusion, the subject of each delta message would be clearly labeled. | |||
To prevent potential malicious emails from doing bad things during the update, we plan to sign our messages using a PIN implementation. This setup will be similar to the Google Sync feature. | To prevent potential malicious emails from doing bad things during the update, we plan to sign our messages using a PIN implementation. This setup will be similar to the Google Sync feature. | ||
== Delivery == | === Delivery Options === | ||
* | The delivery mechanism should anonymous from the details of the actual storage of the message, wether it be IMAP or POP3. The sync service should be able to pass down something like a file pointer to a temporary sync file. The advantage to storing the updates in an individual file is to keep away from the actual "live" data files, and perhaps create the ability to format the update file in a format of our choosing. | ||
* | |||
At this stage, we have not determined if the storage options in the delta messages, here are the options I have come up with so far: | |||
* Store all updates for current iteration in one file | |||
* Store each update in an individual delta message | |||
* Store each individual update as individual files in one delta iteration. | |||
== Service Synchronization Notes == | == Service Synchronization Notes == | ||