incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: MIME dump/load and implications
Date Thu, 06 Aug 2009 20:52:11 GMT
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
>

Mime
View raw message