Skip to main content

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.

Jump to: navigation, search

Org.eclipse.higgins.cardsync.web

Revision as of 14:33, 11 July 2009 by Ptrevithick.gmail.com (Talk | contribs) (Implementation)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Web app that presents the RESTful CardSync API endpoint over the I-Card Service.

Version

org.eclipse.higgins.cardsync.web is being developed as part of Higgins 1.1.

Used By

Original Requirements

Here are the original design goals for the CardSync Web App:

  1. Support a RESTful interface (not SOAP)
  2. Only use protocols and technologies that are available royalty-free, are well documented
  3. Support selectors that support N>1 cardstores
  4. Allow a selector to work completely offline
  5. Support bi-directional synchronization of individual cards and individual metadata entries about these cards
  6. Support strong authentication from client to CardSync server

RESTful API

Implementation

Architecture

This component fits into the this larger architecture:

CardSyncComponentDiagram.png

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

Back to the top