Notes from Higgins Selector Harmonization meeting
Attendees: Alexander, Andy H, Paul, Jeesmon, Brian
Discussion Notes: - Sent out open email to HIggins Dev team on Sunday 1-Feb to announce this project to wider audience.
- Open issues review - see the list of items here: http://wiki.eclipse.org/Selector_Architecture_Harmonization#Open_Issues
- Use of WebDAV - our assessment at this point is to not pursue WebDAV. The main reasons are it is not RESTful and there are issues with web-cache and proxy management (from W3C perspective). Does not appear to be significant advantages to make it worthwhile to pursue.
- Use Google protocol buffer - Would need to assess this for factors such as clean IPR, multiple implementations and strong documentation to help ensure broad support and adoption. Also discussed going with our own SOAP or RESTful protocol and where each would be more appropriate. There was general observation made of the places where SOAP and RESTful solutions are most appropriate: Often a RESTful approach is best where client is talking to sever via trusted connection and is lighter weight. SOAP on the other hand is appropriate where one needs long, possibly untrustworthy handoff to many server endpoints. However with SOAP need to verify integrity of message. Based on this general assessment, for the Higgins selector harmonization we will move forward with a RESTful based approach. Please voice fact based points if anyone feels this is not the correct approach.
- We will also pursue use of Jersy/JAXRS -
- What we need to demo for March FC2 meeting - We discussed the high level demo goals for the FC2 meeting in March:
- Show client side DigitalMe core (Andrew working this piece) talking to Higgins development BE being put together by Alexander.
- We will plan to be able to demo this on a Mac
- The basic workflow we would like to show includes: Prompt for un/pw for log-in to selector, show an existing set of i-cards. Demo log-in to an example RP site. Show creating of a new pcard in DigitalMe and then demo being able to access these same cards via another selector (e.g. iPhone).
- Discussion of general selector interface to LICS:
- In the long run (1yr+) would like to have AIR UI running on DigitalMe/LICS core client side code.
- The general interface model we are returning to is to have a pluggable UI that communicates LICS via xmlrpc (or some other) calls. Would like the LICS have same interface as server-side ICS over the period of a couple of years to fully harmonize these components.
- The design intent is to preserve stateless LICS (RESTful). We would however need to look at making sure we are not passing long term credentials across the wire. Eventually should be able to have LICS run on a remote server as well on client.
- We identified an OPEN ISSUE that needs to be worked through: Need to have verification/authentication between selector and browser plug-in to LICS. This needs to consider factor in design of LICS.
- General development status
- Andy - organizing the Higgins and DigitalMe code into necessary components to support this project. Trying to make sure we are not making local copies into these sub-projects so the bug fixes will benefit all components. Will work on making a new page to capture Andy's new solution organization.
- Alex - Continue to refine the design points for cardsynch protocol. Will have another update to wiki page next week for review. Please see this page to review the latest: http://wiki.eclipse.org/CardSync_Protocol
Please let me know if you would like to be included in the next selector harmonization meeting.
regards...Brian
Brian Walker =brian.walker VP of Engineering Parity Communications Inc cell: 781-801-0254
|
