couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: "Personal" Couch DB.
Date Thu, 25 Jun 2009 06:28:20 GMT
This thread brings me to some thoughts.
We could maybe achieve something like what you desire the following way:

1) Make sure "version" information is placed into .couch files in some way
if it isn't yet, from 1.0 forward.
2) Allow couch to read and convert files produced by an older version.

3)
    a)
        i)  Allow replication to/from file:/// urls
        ii) Associate a script to trigger pull replication from file:///path
associated with .couch files
        iii) Get CouchDB installed all over the place
    OR
    b) Create an executable with a browser interface and an embedded CouchDB
instance

----------------
I think 3a is far more exciting and smarter.
For 3b, a xulrunner window and an erlang interpreter running in one process?
I don't know.

Of course, here I'm assuming that the "clever" user wants to play in Futon.
The analogy here would be the Dreamweaver user who (gasp!) opens their .html
file in Notepad sometimes (assume their application does not offer some
functionality analogous to "view source").

I'm just thinking out loud, but I think reading/writing to .couch files in
arbitrary locations is an interesting idea. Either that or it's late and I
need to sleep. I know we want all db files in one directory so they can be
scanned at start-up, for sure, but is there any reason we couldn't allow the
explicit opening of another file somewhere else? I don't know the code well
enough to say off the top of my head, but I suspect once a port is open to
that file, the core of CouchDB doesn't care where it lives. View index files
could always be kept in one place so as not to clutter someone's usb stick,
for example, just because they opened a .couch file. (In these use cases,
datasets are probably relatively small, and losing the view index when you
take your .couch with you might not be a problem).

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message