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"
(→Surrounding Architecture) |
(→Architecture) |
||
Line 12: | Line 12: | ||
* [[CardSync Synchronization]] - Synchronization process | * [[CardSync Synchronization]] - Synchronization process | ||
− | === Architecture=== | + | === Surrounding Architecture=== |
[[Image:Cardsync-service-1.1.100.png|center]] | [[Image:Cardsync-service-1.1.100.png|center]] |
Revision as of 09:44, 12 July 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Web app that presents the RESTful CardSync API endpoint over the I-Card Service.
Contents
Version
org.eclipse.higgins.cardsync.web is being developed as part of Higgins 1.1.
Implementation
- CardSync Synchronization - Synchronization process
Surrounding Architecture
The following diagram provides more details; it shows interconnections between sub-components (called components in this diagram) between components shown above:
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 using the CardSync Web App? <-- an outcome that would increase interoperability in the industry
Decision:
- We will NOT use Google protocol buffers