Vâng, tôi có thể tự trả lời.
CalDAV
CalDAV là một giao thức trên đầu trang của WebDAV đó là một phần mở rộng của HTTP giao thức. CalDAV được mô tả trong RFC 4791. Nó sử dụng iCalendar làm định dạng dữ liệu. Có rất nhiều triển khai.
Giới thiệu về xung đột CalDAV sử dụng mã trạng thái 409 Conflicts (HTTP 1.1). Khách hàng phải xử lý mã lỗi này, theo như tôi biết, iCal (máy khách Mac) chỉ cần hoàn nguyên các thay đổi cục bộ. Sau đó, nó khá dễ dàng để xác định các quy tắc trong máy chủ để biết phải làm gì nếu có xung đột, nếu bạn không thể giải quyết một trong số chúng, sau đó chúng tôi chỉ cần gửi mã trạng thái 409.
Theo tiêu chuẩn, CalDAV được dành riêng để quản lý dữ liệu lịch và có rất nhiều khách hàng.
Thật không may, Android không cung cấp bất kỳ giải pháp tự nhiên để sử dụng giao thức này, thực sự nó không cung cấp bất cứ điều gì khác hơn là Exchange ActiveSync (được sử dụng bởi Google). Nhưng có rất nhiều khách hàng của CalDAV trên Android Market.
iOS có hỗ trợ gốc của CalDAV.
SyncML
Synchronization Mrkup Ngôn ngữ là một ngôn ngữ đồng bộ nền tảng độc lập để quản lý dữ liệu, tạo ra bởi các công ty lớn như Nokia, IBM, ... Đây là một tiêu chuẩn mở. Nó sử dụng HTTP như giao thông và XML để mô tả thông tin. Có một số cài đặt máy chủ khác nhau, Funambol là một ví dụ điển hình.
SyncML mô tả Bảy đồng bộ:
- hai chiều Sync: cả máy chủ và chia sẻ khách hàng thông tin về những thay đổi, nhưng các khách hàng là người đầu tiên mà gửi các thay đổi;
- Đồng bộ hóa chậm: khách hàng gửi tất cả dữ liệu của nó. Máy chủ xác định một delta giữa dữ liệu của nó và dữ liệu của máy khách, sau đó máy chủ gửi đồng bằng này. Nó thường được sử dụng trên đồng bộ hóa đầu tiên;
- Đồng bộ hóa một chiều, chỉ ứng dụng khách: máy khách gửi các thay đổi tới máy chủ;
- Làm mới đồng bộ hóa từ ứng dụng khách: máy khách gửi tất cả dữ liệu của nó, máy chủ gửi tất cả dữ liệu của nó;
- Đồng bộ hóa một chiều, chỉ máy chủ: máy chủ gửi thay đổi cho ứng dụng khách;
- Làm mới đồng bộ hóa từ máy chủ: máy chủ gửi tất cả dữ liệu của nó, máy khách sẽ thay thế dữ liệu của nó bằng dữ liệu của máy chủ;
- Đồng bộ hóa thông báo máy chủ: máy chủ yêu cầu khách hàng bắt đầu đồng bộ hóa nhất định.
SyncML xử lý conflits trên máy chủ với một bộ quy tắc được xác định trước như Updates mades on the Client always win, Updates mades on the Client always win ...
SyncML là dành riêng cho đồng bộ hóa dữ liệu nhưng không iOS cũng không Android hỗ trợ nó. Điện thoại thông minh Nokia hoặc Samsung dường như hỗ trợ giao thức này, cũng như Windows Phone 6.
Vì vậy?
Microsoft Exchange ActiveSync là lựa chọn tốt nhất để hỗ trợ hầu như tất cả điện thoại thông minh và khách hàng nặng. Nhưng, nó không phải là một tiêu chuẩn mở, và nó là thương mại, và tôi đã không mô tả nó vì những lý do này, chỉ cần nhớ nó.
Về hệ điều hành di động:
- Android không hỗ trợ bất cứ điều gì khác hơn là ActiveSync, nhưng một số CalDAV khách hàng tốt tồn tại;
- iOS hỗ trợ CalDAV nhưng không hỗ trợ SyncML và theo như tôi biết, không có ứng dụng SyncML cho dữ liệu lịch (Funambol cung cấp ứng dụng khách cho liên hệ);
- Windows Phone 7 không hỗ trợ bất kỳ điều gì khác ngoài ActiveSync;
- RIM (BlackBerry) dường như không hỗ trợ CalDAV nhưng có các ứng dụng khách SyncML;
- Tôi không chắc về HĐH khác (như Bada,…).
Tại Pháp, iOS chiếm 60% thị trường điện thoại di động và Android có 30%.
Giải pháp tốt nhất (ít nhất là cho tôi), là bắt đầu bằng cách triển khai máy chủ CalDAV với một bộ quy tắc tùy chỉnh để xử lý xung đột và sau đó triển khai máy chủ SyncML để trang trải phần còn lại của thị trường.
Tôi không thấy cách bạn có thể xử lý xung đột với CalDAV. Không bao giờ có bất kỳ '409 Xung đột' nào từ những gì tôi đã thấy. Thay vào đó, các máy khách (iOS/DAVDroid) đồng bộ hóa ('PROPRIND' /' REPORT') trước khi đẩy ('PUT'). Vì vậy, nếu có một đối tượng lịch mới hơn trên máy chủ, nó sẽ ghi đè lên thay đổi cục bộ. Trong trường hợp này, khách hàng không bao giờ thông báo cho máy chủ về thay đổi cục bộ! Vì vậy, những thay đổi như tham gia sự kiện có thể bị bỏ qua hoàn toàn và không có cách nào để giải quyết nó ở phía máy chủ ... – KrisWebDev