Joel, Not a big deal as I’m not a native English speaker either. ;-) I appreciate your help. Yes, my service would be cloudant like, but it would be tailored for my specialized use cases.
As for “couchdb & pouchdb transparent”, what I wanted to achieve: Whenever a query is triggered, it queries against local pouchdb first, and would only switch to remote couchdb if it fails. i.e: the local pouchdb acts more like a “cache” layer. Is this possible to do just with the current interface? Or do I need a thin wrapper for this logic? -Ying > On Oct 2, 2015, at 04:16, Joel Wallis <[email protected]> wrote: > > @Dale and @Ying, I'm sorry if my text sounds aggressive, that was really > not what I meant. English is just my second language so I really don't even > have an idea of how bad "pretending to develop" sounds at the given > context. I was just trying to help. > > Please ignore my message above. > > 2015-10-01 15:55 GMT-03:00 Dale Harvey <[email protected]>: > >> Ying >> >> CouchDB 2.0 has long been in development and is nearing a beta release, I >> wouldnt be switching existing services to it, but for new product >> development, particularly one that needs mango then I would probably >> recommend doing so. Mango is already supported in CouchDB 2.0, pouchdb-find >> will transparently switch to using it if you are speaking to CouchDB 2.0 >> >> And Joel, this isnt really a suitable mailing list for questioning peoples >> 'product differentials' particularly in that aggressive way "pretending to >> develop" >> >> Cheers >> Dale >> >> >> On 1 October 2015 at 17:32, Joel Wallis <[email protected]> wrote: >> >>> You are actually describing Cloudant as the service you are pretending to >>> develop. Do you have any planned diferential for this? (Just asking, as >>> product manager, to help you plan your product.) >>> >>> And, PouchDB can be used as an interface for a completely remote CouchDB >>> database. Is that what you mean with "couch & pouch transparent"? If not, >>> what are the key diferentials for your implementation? (Just asking, as a >>> software developer, to help you plan your implementation.) >>> >>> 2015-10-01 10:34 GMT-03:00 Ying Bian <[email protected]>: >>> >>>> Dear couchdb developers and users, >>>> >>>> I’m new to couchdb & pouchdb and I’m looking forward to some comments >> to >>>> the following problem: >>>> >>>> I want to setup a couchdb service in the cloud and provide an SDK to my >>>> users for them to use in their apps. They can also use pouchdb as a >> local >>>> replication of their data. An important part of the SDK is the query >>>> interface. I want it to be developer-friendly as much as possible. The >>>> map/reduce API is too complex for developers with no similar >> experience. >>>> After some investigation, I think maybe [pouchdb-find]( >>>> https://github.com/nolanlawson/pouchdb-find < >>>> https://github.com/nolanlawson/pouchdb-find>) is worth to try. Its >>>> mongodb like query language is more intuitive in my mind. >>>> >>>> My questions are: >>>> >>>> 1. Pouchdb-find is still in beta and its documents says "This API is >>>> modeled after the Cloudant query API < >>>> https://docs.cloudant.com/api/cloudant-query.html>, soon to be merged >>>> into CouchDB 2.0.” Is the support already merged into couchdb 2.0? >>> What’s >>>> the delivery plan for couchdb 2.0? Is it to safe to switch to 2.0 now? >>>> >>>> 2. I want the query interface to be “couch & pouch” transparent: the >> same >>>> query API would be used for both local pouchdb and remote couchdb. I >>>> suppose this is not a problem. Am I right? >>>> >>>> Any comments would be much appreciated. >>>> >>>> -Ying >>> >>> >>> >>> >>> -- >>> Joel Wallis Jucá >>> joelwallis.com >>> >> > > > > -- > Joel Wallis Jucá > joelwallis.com
