1 / 14

Web Distributed Authoring & Versioning

Web Distributed Authoring & Versioning. Daniel Wittmer Mike Fisk. Outline . Project vision Environment Expected Risks Post Mortem Demo. Project Vision. Users access web servers as file servers Through a mounted file system Through clients with special support

Download Presentation

Web Distributed Authoring & Versioning

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. Web Distributed Authoring & Versioning Daniel Wittmer Mike Fisk

  2. Outline • Project vision • Environment • Expected Risks • Post Mortem • Demo

  3. Project Vision • Users access web servers as file servers • Through a mounted file system • Through clients with special support • Read-only access through normal browser • Server keeps version history of changes • Users can collaboratively edit documents and publish web pages

  4. Technology • HTTP extensions for distributed authoring • IETF RFC 2518 • Already implemented for Apache • Additional extensions for versioning • IETF draft standard • No finished implementations (client or server) • Our project: a versioning server

  5. Project Environment • Standards body (IETF) • Distributed authoring (DA) standardized • Versioning in progress (DeltaV WG) • Apache, WebDAV module • Infrastructure that we don’t control • Supports DA, but not versioning • Open Source Community • C code, security & usability expectations

  6. Standards Risks • We perceived risk that standard could change even though it seemed stable • A new version was released during the project • Better documentation • Negligible technical changes • Some provisions designed to simplify implementation clashed with our design • Poorly designed authorization assumptions • No mapping of original auths to version repository

  7. Design Change: CVS • We planned on using CVS as versioning infrastructure • Despite many identified risks • WebDAV standard specifies that metadata represented in XML • CVS interface didn’t match these requirements well • Value only as a compact storage optimization • Result: Dropped CVS from architecture

  8. Feature Set Evolution • Risks of time to market and developer resources • Shed features along the way in order to meet our deadline (Microsoft model) • Focused on features usable by existing (non-versioning) clients • Developed a strategy for future features

  9. Apache WebDA(V) • Both a boon and a bane • Apache is a popular 142kloc system • Basic WebDAV without versioning is a 94 page standard --- already implemented in 18kloc • Legacy code • Problems using architecture for new tasks • 96 pages of new standard

  10. Greg Stein – Third Wheel • 1996-98 Development Manager, in the Commerce Server and Site Server groups, Microsoft • Co-founder and the Corporate Technologist of eShop, one of the first electronic commerce software companies, before its acquisition by Microsoft in 1996. • Now “non-employed” open source developer • Wrote Apache WebDAV codebase We don’t like his code

  11. Poor Legacy Modularization • Existing WebDAV module has a poorly executed modularization • A monolithic codebase split into pieces • Interfaces very brittle, complex, incomplete • Unexpected time sink • (Risk of bad scheduling estimates) • Our implementation more kludgey than desired • Fixing existing code is out of project scope

  12. Summary Update • On time • Overcame implementation challenges • On budget • Have been stalling on getting boffice space • Streamlined Feature Set • Imperceptible loss to current users

  13. Futures • Future Development Efforts • Add Basic-Server-Workspace Option • Add Basic-Client-Workspace Option • Optimized Storage • Funding Requirements • Gross revenue: $0 (it’s open source) • Need staff of 3 FTE for next FY • If you funnel support through the Free Software Foundation, your support is tax deductible as a charity donation

  14. DEMONSTRATION • Mac WebDA(V) client • Versioning Apache server • Manually enable versioning

More Related