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
Prior to 0.6, this page was used to track the overall status of sharing in Chandler.
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
- 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
- Are there sharing content model tasks that need definition
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).
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
t = r.read()
# parse acl
a = acl.parse(t)
# 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
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
d = newClient()
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
WebDAV over SSL/TLS should work in principle but has some problems with trust dialog and testing at the moment.
Read also PkiSharingWithWebDav?
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.
- 09 May 2005