1 / 48

OSAF Directors Meeting

OSAF Directors Meeting. May 19, 2004. Agenda. Welcome Approval of Minutes and Resolutions Finance Update Chandler Status Update Chandler Interoperability Chairman’s Report. Minutes and Resolutions. Amy M c Devitt. Board Resolutions.

adamma
Download Presentation

OSAF Directors Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. OSAF Directors Meeting May 19, 2004

  2. Agenda • Welcome • Approval of Minutes and Resolutions • Finance Update • Chandler Status Update • Chandler Interoperability • Chairman’s Report

  3. Minutes and Resolutions Amy McDevitt

  4. Board Resolutions • Board to vote on appointment of Mitch Kapor to three year term • Board to vote on Mitchell Baker’s salary

  5. Finance Update Amy McDevitt

  6. Finance/Accounting Update • Common Solutions Group Grant • Audit Issues • Audit begins next week. Hood & Strong planned to present audit results at next BoD Meeting • Audit Committee discussion

  7. Chandler Status Update Chao Lam

  8. Heart of Chandler • Organize and structure information the way people would like • Rich ability to associate and interconnect all kinds of items • Ground-up rethink of user experience including sharing and collaboration

  9. How current PIMs handle items

  10. Items & Collections are the building blocks of Chandler

  11. News • OSAF adds 2 new working groups • 5 new engineers since Jan 2004 • Significant presence at PyCon including Keynote and programming marathon • 0.3 released end of Feb 2004 • 0.4 release scheduled for Oct 2004 • For discussion: Product strategies to accelerate efforts that will leverage open standards earlier (e.g. PKI, WebDAV)

  12. Two New Working Groups • Design - defines what features will be in Chandler, and design requirements for the features. • Applications - builds Chandler's UI and UI frameworks • Services - builds Chandler’s middleware including Notification, Scheduling, Data Access, Discovery & Email services • Repository - builds Chandler’s item-centric repository including data model • Release & QA - build, release and QA management • Community - develops an active open source Chandler community

  13. Hiring Acitivity • Lisa Dusseault - Services Working Group & Standards Architect • Mark Jaffe - Release Engineer • Brian Kirsch - Email Framework Engineer • David Surovell - GUI Framework Engineer • Donn Denman - CPIA Engineer • Now hiring for: • QA Engineer • Performance Engineer

  14. 0.3: Architecture Release • Base architecture framework in place: • Chandler Presentation and Interaction Architecture • Repository enhancements including transactions and multi-threading support • Content Model • Parcel loading • Agent (scheduling) and Notification Framework • Unit Tests Framework and real tests(!) • Our initial “Caterpillar” UI • Design docs for 0.4 • Shipped Feb 26, 2004

  15. 0.4: Our Big Bang Release • Goal is to be experimentally usable for a few key end-user tasks: • Enter and edit items and collections • Organize and label items and collections • Share and communicate items and collections • UI Landscape: Sidebar, Tabs, Summary & Detail views • Initial functionality for Email, Calendar, Tasks & Contacts • Base security framework • Elementary sharing: e.g. share Calendar and Contacts • More on wiki page Chandler.ZeroPointFourPlanning • Anticipated release date: Oct 2004

  16. Leveraging Open Standards • Originally, we conceived of Chandler-to-Chandler communication through mainly proprietary protocols for Canoga • Then, in Westwood we planned to migrate to open standards • Current thinking: let’s experiment with proven open standards to see how to serve Chandler-to-Chandler communication needs NOW

  17. Accelerating integration of Open Standards • PKI and TLS for secure authentication and transport • WebDAV as basis for Repository Access Protocol • item-centric • peer-to-peer • WebDAV-based calendaring protocol (CalDAV)

  18. What does this mean for Westwood? • With successful experiments, we can minimally accelerate the following Westwood requirements: • Public Key Certificate-based security • Standards-based calendaring client including iTip/iMip support • Import/Export between external PIM apps • PDA synchronization • For discussion: what is the minimum Chandler product that we can deploy in handful of small workgroups on campus?

  19. Key Challenges • Core team in place. Architecture & Design largely in place. Execution is key. • Fine-tuning development process to ensure maximum performance • Working out a realistic product schedule & strategy to satisfy both Canoga (small workgroup) and Westwood (campus-wide deployments) users • Engaging community to achieve higher leverage long-term. • Aligning community goals with development goals

  20. Chandler Interoperability Lisa Dusseault

  21. Chandler Protocol Planning Chandlerserver Calendar Web/fileserver Email IMAP, POP, iMIP,SMTP HTTP? Other Chandler RAP PDA

  22. Existing Standards

  23. Modular Protocol Composition Datastore Event server URLs MIME XMPP WebDAV SSL PKI SASL LDAP Directory

  24. Vertical Protocol Design IMAP NNTP CAP HTTP • authenticate • sessions • browse • synch • acl • authenticate • sessions • browse • synch • authenticate • sessions • browse • synch • acl • authenticate • sessions • browse • synch • acl folder newsgrp calendar directory msg post event resource TCP

  25. Canoga: go modular • IMAP/POP3 support required • HTTP/WebDAV support sooner rather than later • Propose HTTP/WebDAV for data sharing • Between Chandler peers • Browsing, search and synchronization • To share contacts, tasks, calendars • To share any Chandler view • Use other standards for other pieces (PKI…)

  26. Why WebDAV • Solves data access requirements • Browse, search, synchronize • Multiple author support • Clear data model for any application semantics • Provides additional benefits • Real HTTP URLs • Simple clients • Extensible protocol • Proven, deployed, open technology • Existing libraries, faster development

  27. WebDAV -- Application Neutral text img vCard vCal Data formats WebDAV Data access SSL/TLS Data privacy TCP Transport Extend classic protocol layering

  28. Westwood: Server Support • Add support for invitations (iMIP) • Server support for repository synchronization • Support calendar server access via standard protocol • CAP - badly designed standard proposal • CalDAV - alternative standard proposal

  29. CalDAV • Give calendars and appointments HTTP URLs • Support iCalendar standard format • Compatible with iMIP standard • WebDAV Access Control • WebDAV SEARCH • Synchronization

  30. Support for CalDAV • Apple ‘iCal’ • Mozilla • Oracle • Cyrusoft

  31. Summary • WebDAV • For reading, writing, addressing repository items • WebDAV + iCalendar = CalDAV • Internet-Draft (work in progress) • Continue research into: • notifications, PKI and peer location problems • Re-evaluate strategy by fall • Engage with standards communities

  32. Calendaring Standards Status • IETF Working group: • been through 5 chairs since 1996 • 8 years of debate over CAP model and design • Design by committee • Changing editors • Changing names CIP, CTP, CAP… • Compare to iCalendar and iMIP: focus  success • Inventing many things from scratch • Session control, feature negotiation • Addressing, hierarchical object access, and queries • Access control, other security design

  33. Current CAP problems • 136 pages and still underspecified • Complex -- both clients and servers • Maintains connection between server and client • No Web addresses defined for calendar items • Data model poorly defined • Offline operation undefined • Not supported by Microsoft, Apple, IBM • Not yet a standard

  34. Where to layer or CalDAV CAP WebDAV BEEP

  35. iMIP, vCalendar and Calendar Servers 2 Cal1 Email1 Email2 Cal2 SMTP CalendarAccess CalendarAccess vCal vCal 3 IMAP 1 4 POP iMIP vCal SchedulingClient Attendee

  36. Modular Protocol Composition SSL URLs WebDAV data DataStore MIME events XMPP URLs Direc-tory LDAP SASL

  37. Chairman’s Report Mitch Kapor

  38. OSAF Working Groups

More Related