Re: [unhosted] step-by-step instructions to add a couchdb node

[mic...@michielbdejong.com]

Hi Benoit,

We got pretty close with the efforts to support remotestorage "natively" on a couchdb instance, especially during Couchhack event in Vienna last summer where you also were, but in the end we decided that it is so much easier to put nodejs proxy in front of it, that we stopped spending time on the "native" implementation. So the easiest way would be to set up jcoglan's reStore, and then set the storage backend to save data to your couchdb instance on a local port.

But if you want to explore client-side (unhosted) web apps in combination with cross-origin couchdb, then pouchdb, combined with a couchdb instance with CORS enabled, looks like a much nicer approach. It will mean that the users of your app have to run a couchdb instance instead of a having to run a remotestorage server, and you would not get the auth model that remotestorage has (you would probably give each app "root" access to your whole couchdb instance), but on the other hand it would allow you to do couchdb-style map-reduce queries on the stored data. I think it depends on what you're familiar with as an app developer, whether you want to develop for pouchdb or for remotestorage. I personally would choose remotestorage, because sharing user data modules between apps is important to me, and map-reduce queries less so, but i can totally see why in a different situation you may choose pouchdb instead.

HTH,
Michiel.

[Benoit Chesneau]

On Wed, Nov 28, 2012 at 6:42 AM, <mic...@michielbdejong.com> wrote:

Hi Benoit,

Hi, 

Thanks for your answer,

We got pretty close with the efforts to support remotestorage "natively" on a couchdb instance, especially during Couchhack event in Vienna last summer where you also were, but in the end we decided that it is so much easier to put nodejs proxy in front of it, that we stopped spending time on the "native" implementation. So the easiest way would be to set up jcoglan's reStore, and then set the storage backend to save data to your couchdb instance on a local port.

So just to be sure, there is no more "couchdb" compat layer right? How would you handle binaries aka attachments in this case. If I authorizes the verb PUT then could /db/docid/attachment works ?  I guess it is but not sure how binaries are handled by the spec. Is a content-type enough? Imo the spec should have some details about that.

 

But if you want to explore client-side (unhosted) web apps in combination with cross-origin couchdb, then pouchdb, combined with a couchdb instance with CORS enabled, looks like a much nicer approach. It will mean that the users of your app have to run a couchdb instance instead of a having to run a remotestorage server, and you would not get the auth model that remotestorage has (you would probably give each app "root" access to your whole couchdb instance), but on the other hand it would allow you to do couchdb-style map-reduce queries on the stored data. I think it depends on what you're familiar with as an app developer, whether you want to develop for pouchdb or for remotestorage. I personally would choose remotestorage, because sharing user data modules between apps is important to me, and map-reduce queries less so, but i can totally see why in a different situation you may choose pouchdb instead.

Indeed.  Though refuge target more usage than couchdb is at the end but having support for both could be interresting. Does remotejs check against a type? Maybe i could advertise both api using the webfinger protocol. 

- benoit