You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Newson <ro...@gmail.com> on 2009/11/02 14:19:49 UTC

RFC3284 support for attachments

All,

I was thinking about being to update an attachment with a binary diff
instead of a full upload (in those cases where the diff would be much
smaller, of course). RFC3284 (http://www.faqs.org/rfcs/rfc3284.html)
seems to document a generic syntax for describing a patch. The idea is
that you would PUT an encoded diff as the body instead of sending the
full bytes. If the attachment's revision matches your PUT's revision,
then CouchDB will apply the delta to its locally stored version to
make the new version. As a further option, CouchDB could store the
delta itself and apply it on fetch. This might complicate compaction,
though.

Interested in developer's thoughts on this. Is it too niche or would
it be useful to lots of folks? Depending on feedback, I'll add a JIRA
ticket to track it. Note: I won't be jumping on this right now but if
it becomes necessary for my project next year I'll start on it then.

B.

Re: RFC3284 support for attachments

Posted by Adam Kocoloski <ko...@apache.org>.
On Nov 2, 2009, at 8:19 AM, Robert Newson wrote:

> All,
>
> I was thinking about being to update an attachment with a binary diff
> instead of a full upload (in those cases where the diff would be much
> smaller, of course). RFC3284 (http://www.faqs.org/rfcs/rfc3284.html)
> seems to document a generic syntax for describing a patch. The idea is
> that you would PUT an encoded diff as the body instead of sending the
> full bytes. If the attachment's revision matches your PUT's revision,
> then CouchDB will apply the delta to its locally stored version to
> make the new version. As a further option, CouchDB could store the
> delta itself and apply it on fetch. This might complicate compaction,
> though.
>
> Interested in developer's thoughts on this. Is it too niche or would
> it be useful to lots of folks? Depending on feedback, I'll add a JIRA
> ticket to track it. Note: I won't be jumping on this right now but if
> it becomes necessary for my project next year I'll start on it then.
>
> B.

I think it'd be pretty sweet.  If Couch stored the deltas we'd  
probably be able to take advantage of this feature in replication,  
too.  I don't think it would complicate compaction all that much.

Adam