Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4A7B4AA1.4090707@borwankar.com>
Date: Thu, 06 Aug 2009 14:26:57 -0700
From: Nitin Borwankar <nitin@borwankar.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: MIME dump/load and implications
References: <921000908061346p38fe9d4arf292d7fae14dafa0@mail.gmail.com>
 <e2111bbb0908061352h33437919ic5d88b05b76d1e25@mail.gmail.com>
In-Reply-To: <e2111bbb0908061352h33437919ic5d88b05b76d1e25@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hi Paul,

I never used the word replication - it should be possible to create a 
REST based couchapp driven MIME transfer p2p web quiteindependent of 
replication which is also cool.  Front the couchapp with the usual 
auth-proxy stuff for now so only auth'ed people can communicate with you.

Just replace JSON with MIME in all the reference docs and make the URL's 
point to a design doc that does the transformations.

On the way out it could be just _shows or an _list that takes multiple 
objects and wraps them as a mime multipart.

On the way in set up some REST endpoints that take POST's, parse mime 
multiparts ( jchris's mimeparser?)  convert to Couch docs, manage 
attachments and puts them in _attachments ... and we're off to the races 
- free user controlled, MIME-and-Mail-as-aplatform driven webmail apps 
for all.
Yay Couch!

Nitin


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<nitin@borwankar.com> 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
>> nborwankar@gmail.com
>>
>>