r4 - 09 Sep 2004 - 10:33:13 - PieterHartsookYou are here: OSAF >  Journal Web  >  ContributorNotes > ChaoLamNotes > RecalibrationMeeting20040819
Here're my notes for the CSG recalibration meeting. They are not intended to be comprehensive notes. Instead, they're meant to capture updates, surprises or suggestions given at the meeting that we had not thought of carefully before.

I'm also covering the two most important issues discussed in the meeting in slide presentations:

  • WAC Server Product Issues: plans of our server product plans, reorganized with key issues framed for CSG consumption based on feedback from this meeting
  • WAC Calendaring Decisions: discussion of calendaring decisions CSG/OSAF needs to make for upcoming WAC meeting

Next WAC Agenda candidate items:

  • Chandler update: 0.4 and 0.5 releases
  • Update on Canoga and Westwood schedule
    • including developer dog food update
  • Security review
  • Server Product Roadmap
    • differences between kibble, hosted, and Westwood
  • Calendaring decisions
  • Marketing Chandler

List of issues discussed at the recalibration meeting

Document as First Class item
  • John suggested two ways to handle foreign files (e.g. attachments from email, photos, mp3 songs):
    • Chandler imports the entire file into the local repository
    • Chandler creates a proxy or delegate item that has a reference to the original file.
  • CSG provided a strong opinion that the proxy solution was preferred in most cases, especially when foreign files are also stored locally
  • Several people noted this is very similar to the concept of "data compositing" we had suggested in the original Higher Education requirements doc, in relation to email items in the IMAP and Chandler repositories.
  • We should work out at least a plausible workflow of how a foreign file tagged with meta-data in Chandler, can be edited by an external application and have its changes synchronized with Chandler as needed.
  • CSG members and OSAF noted that there is a baseline here. In Kibble, we should be doing no worse than what current clients do. That doesn't solve all document management problems, but it's a starting point.
  • This issue was revisited the next day as we discussed a list of big features to drop for Kibble, listed at NotSoOutrageousQuestions. Several CSG members noted that:
    • Because documents are such a key aspect of the generic information management vision of Chandler, it should be baked into the architecture in Kibble
    • We should validate the "document as a content item" model in Kibble. Even if we don't provide basic document organizing functionality, we should make this a developer dog food priority

Calendaring

  • CSG highly encouraged OSAF and Mozilla to get aligned on the same calendaring strategy and to ensure interoperability. Minimally, clarity between OSAF and Mozilla roles would be helpful. In general, higher ed would benefit from more OSAF and Mozilla collaboration and alignment.
  • Event publishing is increasing in importance for higher education. OSAF should update itself on higher ed event publishing requirement and see if Chandler can be be deployed for event publishing even in the Kibble time frame.
Managed Desktops
  • This is an increasingly important requirement.
  • In particular, we should have a self-updating version of Chandler even in Canoga:
    • Chandler client itself needs to be self-updatable
    • Provide hooks to allow third-party parcels to self-update
    • Users should be presented with information on what the update patch is about, including info about what the patch fixes and its severity.
  • Suggestion was made to integrate and use LDAP as a means for automating account creation and account customization (e.g. user profiles)

Security

  • Security issues continue to be paramount as higher ed IT function. Good news is that many more people now acknowledge and recognize this and there is increasing acceptance for central management
  • Would be nice if Chandler is architected so that openSSL is replaceable (e.g. with NSS)
  • Security issues on features we are considering dropping from Kibble Code sharing at end-user level e.g. Allowing users to share filters
    • Scripting
    • CSG members noted that these are potentially problematic areas that we need to keep in mind for our security audits. We noted that these are features we have discussed in our vision for Chandler, but are definitely not going to be in Kibble and probably not for Westwood.
  • Encryption of the store (as opposed to during transmission) is not essential but a nice-to-have. Probably post-Westwood

Sharing

  • We should consider Shibboleth as a means for extranet sharing

Email

  • Several CSG universities offered their IMAP servers as test servers for OSAF

Deployment policies. Following are types of deployment policy "knobs" that we want to provide in Westwood

  • Limits of extensibility (e.g. no 3rd party parcels, only only "blessed" ones)
  • Predefined preferences (different from standard Chandler defaults)
  • Redirecting and controlling how Chandler gets automatic updates and patches
  • "Kiosk mode" toggle would set a whole bundle of policies

Server Product

  • Requirement: Admin access into personal accounts for legal reasons (e.g. subpoena
  • Need to describe phase implementation plan and options in better details. Focus areas:
    • Canoga server product only intended to store shared collections, not entire user repositories
    • We server syncing collections and replication of entire repository as two possibly distinct features. The latter being able to support multiple-machine nomadic usage mode (accessing the same Chandler data from multiple machines e.g. home vs. work machine)

Other new higher ed developments:

  • Shibboleth deployment and acceptance faster than anticipated
  • Wireless, PDAs and multiple devices are proliferating on campuses and are pass the tipping point
-- ChaoLam - 23 Aug 2004
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < 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.