Ticket #64 (assigned Enhancement)
Extract attachments from iCalendar resources
| Reported by: | wsanchez@… | Owned by: | wsanchez@… |
|---|---|---|---|
| Priority: | 3: Important | Milestone: | Later |
| Component: | Calendar Server | Severity: | Performance |
| Keywords: | Cc: | kurt.leubner@… | |
| Port: |
Description (last modified by wsanchez@…) (diff)
If a client writes an iCalendar resource with an attachment in it (encoded inline, rather than referenced by URI), the iCalendar data will be large. This is problematic if the client wishes to make a small (in terms of data size) change to the iCalendar data, such as changing the event title or time, because it will also have to re-upload all of the attachment data as well. A change of a few bytes could end up requiring megabytes (or more) to be sent over the wire.
A solution I'd like to pursue involved the server extracting the attachment from the resource during PUT, parking the attachment in a different location, and rewriting the iCalendar data to reference the attachment resource by URI.
Change History
comment:1 Changed 7 years ago by wsanchez@…
- Status changed from new to assigned
- Description modified (diff)
comment:2 Changed 7 years ago by wsanchez@…
Some reasons why this stragegy is appealing:
- The client sends the event and it's attachments in one request, which means that cleaning up after failures is easier.
- The server takes ownership of managing the attachments. For example:
- The permissions on the attachment can be inherited from the event, which is generally expected, without the client having to ensure this. Note that there is no way for clients to ask a server to cause one resource to inherit ACEs from another.
- If the event is deleted or moved to another calendar, etc., the server can delete or move the attachment. Relying on clients to ensure this is highly error prone (eg. a client which doesn't support and knows nothing about attachments does the deleting), which would result in (large!) cruft on the server.
Some reasons why this stragegy is not appealing:
- Some clients get weirded out if the server rewrites their data. The clients are broken. Since CalDAV is new, so are all CalDAV clients, and I assert that forcing them to behave correctly in order to interoperate is OK.
- Clients has to go through a number of steps to ensure they have the correct data.
- Clients have to be thoughtful in order to reduce the over-the-wire traffic when dealing with attachments, including using MD5 sums (or something similar) to avoid reloading unchanged attachment data.
- This relies on servers to provide MD5 headers; most HTTP servers do not do this, but we can ensure that ours does.


Here is a summary of what I think the steps involved might be: