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 23:11, 10 July 2009 by Ptrevithick.gmail.com (Talk | contribs) (Should we use Google protocol buffers?)

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

Higgins logo 76Wx100H.jpg

Web app that exposes a RESTful 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