r1 - 11 Jun 2004 - 20:30:00 - KatieCappsParlanteYou are here: OSAF >  Journal Web  >  ContributorNotes > KatieParlanteNotes > KatieParlante20040610

Notes from meeting w/Chao, Mitch, Lisa

We're going to explore a particular proposal (the famous proposal #4, a server model), evaluating it to these criteria:

  • How well does the candidate proposal support design requirements? Note that some requirements are mutable, others are not.
  • How does the proposal fit with the rest of the chandler architecture? An example: are/how are bidirectional links preserved in the translation to a standard representation on the server?
  • How do we address service and deployment issues?

Advantages to a server based solution:

  • Better availability
  • Public availability
  • Web based technologies pose a lower technical risk. A single source of truth poses a lower technical risk for n-way sharing/synchronization.

Next actions:

  • Lisa to drive the network architecture, including meeting up with Mitch and Jurgen to understand options for a low IT impact server.
  • Chao to do a next iteration on design requirements.
  • Katie to drive issue resolution around how proposal affects "chandlerness" in the rest of the architecture, including the data model. Related issue is to get engineering on the same page regarding understanding the landscape and the options.

Lisa proposed possible staged implementations (B, C, D do not necessarily happen in that order, but presumably preceed E):

  • (A) publish/read only
    • owner publishes to server, publicly readable
    • consumer downloads from server into their local repository, read only, offline readable
  • (B) remote browsing, don't wait to synchronize all before showing data
  • (C) share read/write w/locking, then share w/user resolving conflicts
  • (D) consumer can annotate shared data, perhaps link to internal data
  • (E) "true sharing"

Lisa proposed an architecture for publishing collections (in particular calendars) as web pages (read only -- no forms):

  • an html "template" w/javascript sits on the server w/webdav access (user data sits on server as well)
  • a stylesheet sits on the server
  • the html page (served to the browser) pulls in the live data, stylesheet formats
  • requires browsers to grok webdav so that the javascript can pull the data
  • in theory, chandler could generate the stylesheet and html template, using cpia to drive custom formatting

-- KatieCappsParlante - 12 Jun 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.