r41 - 31 Aug 2005 - 15:19:37 - GrantBaillieYou are here: OSAF >  Projects Web  >  DevelopmentHome > ServicesWorkingGroup > WebdavService

WebDAV Service Project

The goal of this project is to support Chandler sharing over http, mostly by leveraging the high-level zanshin protocol library. This page tracks zanshin-related tasks in Chandler: This includes development of the library itself as well as integration issues for the Chandler Sharing Project.

Note: Prior to 0.6, this page was used to track the overall status of sharing in Chandler.

People

  • GrantBaillie
  • MorgenSagen
  • HeikkiToivonen
  • LisaDusseault

Current Tasks

Task Owner Status Duration Milestone
Chandler integration: sync API Grant Done 3 days M3
Chandler integration: sync "Test this account" Grant Done 2 days M3
Chandler integration: sync sharing Grant Done 4 days M3
ETag support Grant Done 3 days M3
Ticket support Grant Done 3 days M4
CalDAV extras Grant Done 5 days M5
Further ETag support (If-Match: etc) Grant In progress 5 days M5
Deleting shares (tombstones) Grant   3 days M6
zanshin docstrings and tests Grant In progress 3 days M6
High level ACL API Heikki     M5

References

  • SharingProject: Higher-level view of Chandler's Sharing architecture.
  • The 0.6 Sharing Design Spec.
  • The 0.6 Zanshin Spec.
  • The 0.2 Chandler Server Spec.
  • Morgen's ideas for sharing collections interoperably (i.e. with Chandler and other clients).

Unscheduled tasks

These need to be reviewed for applicability for 0.6.

  • Instrumentation: Log counts of change uploads, merges required, and unmergable conflicts
  • Smart change-merging to minimize conflicts when ETags differ
  • Handle Content Items with multiple bodies
  • Integrate Exportable Addresses work (depends on Ted)
  • Store two copies of any Item that has user-change conflicts, or other mechanism to allow users to compare versions to deal with conflicts.
  • Set ACLs when publishing to server (low level API available in 0.4.07)
  • Download (synchronize to local) ACLs
  • Add pipelining to dav client library
  • Make calendar event bodies be iCalendar, architecture to support arbitrary bodies
  • In-band invitations to share (this may be a different component)
  • Make Chandler be a WebDAV server

Interoperability improvements:

  • Fix namespaces of properties -- rather than use the attribute's path, we need to use something like the namespace that was defined for that attribute in parcel XML.
  • Figure out what to do to synchronize unrecognized properties stored on the server resource. Currently they're ignored.

Performance improvements for post 0.4:

  • Reuse the DAVItem rather than constructing new
  • Don't do a PUT to force the ETag to change -- instead, have an independent way of tracking property changes (manually generated PTag?)
  • Make it so that _getEtag and _getLastModified don't each cause a round-trip HEAD.
  • Generally investigate wasted round-trips

Dependencies:

  • Are there sharing content model tasks that need definition

ACL

The WebDAV ACL API has a lower level implementation as of the 0.4.07 timeframe. Basically, it's possible to read the acl property for a resource, parse the returned XML into ACL object (Python) which allows easy manipulation of the ACL, and finally set the ACL on the resource (sending the ACL command with the serialized ACL object as body of the request).

See acl.py for the ACL implementation. WebDAV.py has the getacl/setacl methods.

Below is a code sample that reads the ACL of a resource, parses the XML, then sets it to what was parsed. The ACL after all this should match what it was when we got it originally.

    file = '/heikki/myfile.txt'
    d = newClient() # d is an instance of WebDAV.Client
    # get acl
    print '---getacl---'
    r= d.getacl(file)
    t = r.read()
    print t
    # parse acl
    a = acl.parse(t)
    print '---parsed---'
    print a
    # Now we have the ACL object, see the acl.py file for documentation on how to change it etc.
    # This newClient() stuff is needed in case of SSL because of Bug:2408
    r.close()
    d = newClient()
    r= d.setacl(file, a)
    print '---set parsed---'
    print r.status, r.reason
    # This newClient() stuff is needed in case of SSL because of Bug:2408    
    r.close()
    d = newClient()
    r= d.getacl(file)
    print '---getacl---'
    print r.read()
    r.close()

A higher level API is in the works. This will include features like parsing the support-privilege-set property and using that information to automatically map requests to the correct settings on the server and so forth.

New API and implementation stuff

  • Decision: not trying to preserve original ACL XML markup
    • order of attributes, elements can change; namespace prefixes can change, non WebDAV namespaced content will be dropped, comments and PIs can be dropped, entities can change presentation
  • Design: charset

PKI

WebDAV over SSL/TLS should work in principle but has some problems with trust dialog and testing at the moment.

Read also PkiSharingWithWebDav.

History

Release 0.5 tasks

Task Owner Status Duration Milestone
WebDAV operation: Unpublish a share Morgen   3 day(s) 0.6
Low level ACL API (set, get, parse XML) Heikki done   0.4.07
High level ACL API Heikki     0.6

Release 0.4 tasks

  • SharingFunctionalSpec -- this spec describes the GUI exposing the 0.4 WebDAV collection sharing, as well as some of what happens under the covers. See also the section with simplifying assumptions, below.

Previous tasks to re-evaluate:

Task Owner Next Actions SWAG Priority Milestone
Webdav Client Library integrated Stuart Done med now 0.3.16
Export/import normal items Stuart Done med now 0.3.21
Export/import bidi links Stuart Done med now 0.3.16
Develop base Python object/methods for item collections Stuart Done med now 0.3.18
Export entire collections Stuart Done med now 0.3.18
Unit tests for export/import -- detect connection & use server Stuart Done med now 0.3.23
Import entire collection to new local collection Stuart Done med now 0.3.23
Store ETags of imported items Stuart Done med soon 0.3.23
Handle Content Item clouds Stuart Done med now 0.3.23
Synchronize changes locally with changes on server (requires 'dirty' flag if changes made locally) Stuart Done med soon 0.3.23
unit tests connection detection Stuart Done med now 0.3.23
Maintain attribute with last known successful synchronize event on shared collection Stuart Done small soon 0.3.23

WebDAV? in 0.4"> Sharing via WebDAV in 0.4

This section explains the simplifying assumptions and limitations of how sharing works over WebDAV in 0.4 release. Sharing in 0.4 was the work of StuartParmenter.

The model for sharing via WebDAV is that you can publish a collection (in particular, a calendar) to a WebDAV server in order to share it with others. Once the collection is published, the sharer and the sharees can all synchronize to the server in order to get up-to-date content and to make content changes. Synchronization will happen on a polling schedule, probably every 10 minutes. Thus, the delay for user A seeing a change from user B can be nearly 20 minutes in even normal cases: user B makes a change immediately after a synch, so the change isn't noticed locally for 10 minutes. Then if user B's synch event happens just after user A's synch event, it will be nearly 10 minutes before user A notices that the data on the server has changed and to download it. If the synchronization event fails in any way, we will simply log it and not bother the user.

Changes will be determined based on ETag, for the sharer as well as the sharees. This implies that every shared resource will need a place to store its ETag so that during synchronization we'll notice that the resource needs updating. As well, each resource will need a 'dirty' flag so that we'll know when it has been changed locally and the changes need to be uploaded. If changes are made offline, this approach should capture those changes too.

We won't allow any resharing of an item in 0.4. It will be possible to attempt that -- a user can subscribe to a collection containing an event, drag that event into a local collection, then try to publish that local collection (or perhaps it's already setup for publishing). We'll detect this by having each shared resource have a way to indicate what collection it's shared in (possibly by storing its server URL). If the item indicates that it's already shared through one collection, we won't upload it to any other collections. We'll silently skip over such items, only noting the 'error' by logging the fact that we skipped over an item rather than resharing it.

Also in 0.4, we are not intending to have any fine control over who can subscribe. We won't add ACL client support to the WebDAV client library, so there's no way to limit read/write access to certain users through Chandler (although it can be done by the WebDAV server administrator). There won't be any way to see who has subscribed, what their subscribe status is, or when they last downloaded/synchronized.

There may be unresolvable conflicts when two users have edited the same item in the same timeframe. If there are unresolvable conflicts we will simply use an error dialog to alert the user that their changes are being lost. Instead of keeping the user's changes, we will simply overwrite the user's changes with the information from the server. This is not the long-term design, of course, but merely a simplifying step for now.

There may be more simplifying choices or assumptions; we're currently discussing whether or not we will attempt to do merging, pretty URLs, handling multiple items. We may not have a good way of updating the detail view for the item that's currently being viewed if new information is downloaded while the user has the detail view open, so users probably won't see changes in an item unless they click on another screen first and then come back.

-- GrantBaillie - 09 May 2005

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r41 < r40 < r39 < r38 < r37 | 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.