r6 - 13 Jul 2007 - 05:49:08 - MimiYinYou are here: OSAF >  Journal Web  >  CosmoZeroDotSeven > ClientSideInfrastructureForCosmoDashboard

Introduction

This page based on 21 Feb 2007 meeting between Bobby and Travis.

We believe that the implementation of the Dashboard features require three sets of infrastructure changes:

Model Changes

To support additional types of data (such as tasks, emails, etc) we will need to extend our data model. To support items or more than one data type, we believe a model similar to Chandler's is most appropriate. This consists of generic "Note" objects "annotated" with "Stamp" objects.

  • Tasks
    • Stamps:
      • Introduce single "Note" object
      • Introduce "stamps" like those used in Chandler
        • Convenience syntax for attribute access: EventStamp(note).startTime === note["osaf.pim.calendar.EventStamp.startTime"] (?)
        • EventStamp, TaskStamp, EmailStamp, (?)
  • Why?
    • We need to expand our data model anyway, and it makes sense to use a model very similar to Chandler's

Service layer

To ensure the stability of this more complex system, we need a formalized data access/ modification layer. While this will be similar to the current system for data access and modification, we believe some changes are required. In short, this layer will be called directly from the UI. It should not need extra layers of indirection (like topics). It will encapsulate synchronous or asynchronous actions. In the case of asynchronous actions, topic communication should be used to handle return values (see below). We have made a decision not to implement client side caching/ repository-like features.

  • Properties
    • Called directly by ui (not via topics)
    • Save, delete, etc (all operations currently handled by conduits?)
    • No caching/ formal "repository like" storage of data
  • Tasks
    • Decide on terminology (data access object? conduit? data service?)
    • Decide on API (like conduit api?)
      • Do we need "call ids?"
    • Implement service layer
    • Move all data access calls to service layer
  • Why?
    • We should not be making server calls directly from the UI
    • Repository structure "too heavyweight"

Formalized topic communication conventions

To further support the stability of the system, and to help solve the UI updating problem (and any other "event notification" problems) we need to further solidify our conventions for using topics. In short Topics is meant to solve the problem of ui elements being informed of data changes without having to manually talk to each ui element.

  • Properties
    • Called by service layer in response to actions
    • Events like "save succeeded," "save failed", etc
  • Tasks
    • Formalize list of topics
    • Add topic publishing code into return from "service layer" calls (see above)
  • Why?
    • Backend half of "ui updating" problem

-- TravisVachon - 21 Feb 2007

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r6 < r5 < r4 < r3 < r2 | 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.