You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jan Lehnardt (JIRA)" <ji...@apache.org> on 2008/07/14 22:24:31 UTC
[jira] Resolved: (COUCHDB-63) Do not require attachments to be
encoded in base64
[ https://issues.apache.org/jira/browse/COUCHDB-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Lehnardt resolved COUCHDB-63.
---------------------------------
Resolution: Fixed
Fix Version/s: 0.9
As of revision 675699, CouchDB has a RESTful API for attachments that doesn't require base64 encoding of data.
> Do not require attachments to be encoded in base64
> --------------------------------------------------
>
> Key: COUCHDB-63
> URL: https://issues.apache.org/jira/browse/COUCHDB-63
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Environment: All
> Reporter: Jan Lehnardt
> Priority: Minor
> Fix For: 0.9
>
>
> At the moment an attachment's data must be encoded in base64. With larger attachments this leads to significant overhead on the client. It would be nice if the encoding would not be required and data could be stored as-is.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (COUCHDB-63) Do not require attachments to be encoded in base64
Posted by Dean Landolt <de...@deanlandolt.com>.
Oh. Thanks. I'm just starting to get into this whole TDD thing -- I should
know by now to just look for the tests. They usually contain answers to most
of my usage questions. Thanks again Jan.
On Tue, Jul 15, 2008 at 10:25 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Jul 15, 2008, at 15:50, Dean Landolt wrote:
>
> Jan Lehnardt resolved COUCHDB-63.
>>> ---------------------------------
>>>
>>> Resolution: Fixed
>>> Fix Version/s: 0.9
>>>
>>> As of revision 675699, CouchDB has a RESTful API for attachments that
>>>
>> doesn't require base64
>>
>>> encoding of data.
>>>
>>
>> Thanks for getting this feature in. Is there any documentation on this new
>> API? I've seen a lot of mention of this coming, but nothing formal to code
>> against. I suppose I could start throwing PUTs and DELETEs against the new
>> trunk to see what sticks, but if there's something already out there, it'd
>> save some time.
>>
>
> See the attachment tests at
>
> http://svn.eu.apache.org/viewvc/incubator/couchdb/trunk/share/www/script/couch_tests.js?view=markup
>
> written docs will follow.
>
> Cheers
> Jan
> --
>
>
Re: [jira] Resolved: (COUCHDB-63) Do not require attachments to be encoded in base64
Posted by Jan Lehnardt <ja...@apache.org>.
On Jul 15, 2008, at 15:50, Dean Landolt wrote:
>> Jan Lehnardt resolved COUCHDB-63.
>> ---------------------------------
>>
>> Resolution: Fixed
>> Fix Version/s: 0.9
>>
>> As of revision 675699, CouchDB has a RESTful API for attachments that
> doesn't require base64
>> encoding of data.
>
> Thanks for getting this feature in. Is there any documentation on
> this new
> API? I've seen a lot of mention of this coming, but nothing formal
> to code
> against. I suppose I could start throwing PUTs and DELETEs against
> the new
> trunk to see what sticks, but if there's something already out
> there, it'd
> save some time.
See the attachment tests at
http://svn.eu.apache.org/viewvc/incubator/couchdb/trunk/share/www/script/couch_tests.js?view=markup
written docs will follow.
Cheers
Jan
--
RE: [jira] Resolved: (COUCHDB-63) Do not require attachments to be encoded in base64
Posted by Dean Landolt <de...@deanlandolt.com>.
> Jan Lehnardt resolved COUCHDB-63.
> ---------------------------------
>
> Resolution: Fixed
> Fix Version/s: 0.9
>
> As of revision 675699, CouchDB has a RESTful API for attachments that
doesn't require base64
> encoding of data.
Thanks for getting this feature in. Is there any documentation on this new
API? I've seen a lot of mention of this coming, but nothing formal to code
against. I suppose I could start throwing PUTs and DELETEs against the new
trunk to see what sticks, but if there's something already out there, it'd
save some time.