Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Org.eclipse.higgins.cardsync.web"
(New page: Web app that exposes a RESTful endpoint over the CardSync core service.) |
|||
| Line 1: | Line 1: | ||
Web app that exposes a RESTful endpoint over the [[CardSync]] core service. | Web app that exposes a RESTful endpoint over the [[CardSync]] core service. | ||
| + | |||
| + | === Version === | ||
| + | [[org.eclipse.higgins.cardsync.web]] 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 | ||
Revision as of 11:48, 6 July 2009
Web app that exposes a RESTful endpoint over the CardSync core service.
Contents
Version
org.eclipse.higgins.cardsync.web 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
Server component diagram
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