incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: MIME dump/load and implications
Date Thu, 06 Aug 2009 21:12:35 GMT
The motivation behind using MIME multipart for replication was to  
allow a document and all its attachments to be transmitted in one go  
without having to do Base 64 encoding.  I haven't done any work on  
this topic, perhaps others have.

Cool stuff, though!


On Aug 6, 2009, at 4:52 PM, Paul Davis wrote:

> Definitely some interesting points here. There have been discussions
> on using multipart-mime messaging in the replication protocol which
> could setup for some interesting prospects like this. I'm not sure on
> specifics in terms of replication, but having an endpoint that allows
> edits via multipart-mime could be a very fun thing to play with.
> Also, AFAIK there's nothing that prevents an isomorphic
> representation. As you point out, couchdb-python handles everything
> just fine here.
> Paul Davis
> On Thu, Aug 6, 2009 at 4:46 PM, Nitin Borwankar<>  
> wrote:
>> Hi guys,
>> I see that the python based dump/load uses MIME multipart docs as  
>> an on-disk
>> serialisation format for couchdb databases.
>> An overall question then arises - can CouchDB be considered a MIME  
>> database
>> which oh also happens to talk JSON?
>> So before that - is there a 1-1 strong correspondence between a  
>> CouchDB
>> document and a MIME multipart, or are there things around the edges  
>> that are
>> crufty - I would assume a strong correspondence since dump/load  
>> uses it and
>> I haven't seen any caveast about document content that is not  
>> dumpable.
>> So assuming the 1-1 correspondence - could one use some  
>> "translation layer"
>> couchapp that accepts arbitrary content/type + multipart-mixed MIME  
>> object
>> over HTTP and then transparenty serialise them to JSON underneath.
>> Given that dump/load already does this - it would see that there  
>> are no
>> obvious glaring flaws in this logic - but I have been known to be  
>> wrong,
>> once :-).
>> If this is indeed feasible - then each CouchDB + MIME-trans becomes  
>> a web
>> mail node - and Couch begins to be the platform for  a messaging  
>> revolution
>> as well as an application revolution. I am thinking now not as  
>> CouchDB for
>> backing up your email - but CouchDB as your mail client/server for  
>> p2p MIME
>> based "email".
>> Permissions etc are important to avoid complete disaster of course  
>> - but
>> private high quality communication that just reuses existing message
>> formats, with better storage and transport would seem like an idea  
>> whose
>> time has come a long time ago and has been knocking at the door for a
>> decade.
>> Yes, yes, there's the issue of spam - so see the P.S.
>> Just a few idle thoughts,
>> Nitin
>> P.S.  Back in 1998 I tried to convince Sybase to have MIME as a  
>> native type
>> in the db and it even got speced out ( I have the spec with the  
>> date on it!
>> ) but got canned becous ethe VP of enginnering wanted to know "what  
>> was the
>> market exactly for this kind of stuff".  Other than that I was  
>> granted  a
>> patent for doing p2p discussions over email back in 2003 - I let it  
>> expire
>> for multiple reasons.  So I am somewhat non-naive about and aware  
>> of the
>> issues and pitfalls around this sort of thinking. At the same time  
>> I am of
>> the strong belief that when one looks at messages as data to be  
>> moved around
>> between endpoints with well defined addressing schemes, and one  
>> ignores the
>> protocols for a bit, then all sorts of fun things start to happen.
>> 37% of all statistics are made up on the spot
>> -------------------------------------------------------------------------------------
>> Nitin Borwankar

View raw message