|
|
| (6 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
| + | #REDIRECT [[CardSync Service]] |
| − | | + | |
| − | [[Image:Higgins_logo_76Wx100H.jpg|right]]
| + | |
| − | | + | |
| − | This page describes the design of the [[CardSync]] API for the Higgins Service 1.1.
| + | |
| − | | + | |
| − | === Version ===
| + | |
| − | This API is being developed as part of [[Higgins 1.1]].
| + | |
| − | | + | |
| − | === Used By ===
| + | |
| − | * This API will be first used by the [[GTK Selector 1.1-Win]] solution
| + | |
| − | * Specifically, this API is consumed by the synchronizing card store that is described here: [[Selector Architecture Harmonization]].
| + | |
| − | | + | |
| − | === Requirements ===
| + | |
| − | CardSync must:
| + | |
| − | # Support a RESTful interface (not SOAP)
| + | |
| − | # Only use protocols and technologies that are available royalty-free, are well documented
| + | |
| − | # Support selectors that support N>1 cardstores
| + | |
| − | # Allow a selector to work completely offline
| + | |
| − | # Support bi-directional synchronization of individual cards and individual metadata entries about these cards
| + | |
| − | # Support strong authentication from client to CardSync server
| + | |
| − | | + | |
| − | === Open Issues ===
| + | |
| − | # Why don't we base our design on SyncML?
| + | |
| − | | + | |
| − | === RESTful API ===
| + | |
| − | * [[CardSync JAX-RS API]] - RESTful API
| + | |
| − | * [[CardSync Authentication]] - RESTful API Authentication
| + | |
| − | * [[CardSync Exceptions]] - coming soon
| + | |
| − | | + | |
| − | === Data Transfer Objects ===
| + | |
| − | * [[CardSync Data Transfer Objects]]
| + | |
| − | | + | |
| − | === Server component diagram===
| + | |
| − | [[Image:CardSyncComponentDiagram.png|800x400px]]
| + | |
| − | | + | |
| − | === Closed Issues ===
| + | |
| − | | + | |
| − | ==== Should we use WebDAV? ====
| + | |
| − | Reasons For:
| + | |
| − | * reduces our development effort as this protocol is designed for resource synchronization. And that's what we're doing
| + | |
| − | * mature, widely supported. Being used in new projects such as Mozilla Weave.
| + | |
| − | Reasons Against:
| + | |
| − | * Not RESTful. WebDAV extends the HTTP verb set. As such is deprecated by the W3C.
| + | |
| − | * Can interfere with web cache architectures
| + | |
| − | Decision:
| + | |
| − | * We will NOT use WebDAV
| + | |
| − | | + | |
| − | ==== Should we use Google protocol buffers? ====
| + | |
| − | Reasons For:
| + | |
| − | * Mature
| + | |
| − | * High performance
| + | |
| − | * Good libraries in both C++ and Java
| + | |
| − | Reasons Against:
| + | |
| − | * Question: Might using protobuf reduce the likelyhood of the CardSpace team collaborating with us and potentially adopting the [[CardSync Protocol]]? <-- an outcome that would increase interoperability in the industry
| + | |
| − | Decision:
| + | |
| − | * We will NOT use Google protocol buffers
| + | |
