Raindrop/BackEndRoadmap: Difference between revisions

← Older edit

Raindrop/BackEndRoadmap (view source)

Revision as of 22:34, 1 December 2009

261 bytes removed , 1 December 2009

remove confidences, add couchdb

Mhammond

Confirmed users

99

edits

@@ Line 3: / Line 3: @@
 This page describes our planning and thinking about the direction the [[Raindrop/BackEnd]] should take.
-== Confidences ==
+== Better leverage of CouchDB ==
-The [[Raindrop/RaindropDocumentModel]] notes that in some cases, extensions will want to provide schemas which 'override' or 'refine' the schemas provided by other extensions.  We intend to do this by adding the concept of a 'confidence' to schemas.  The core extensions will use a default confidence value, and if other extensions can provide better values, they emit a schema with a higher confidence.  However, we want to avoid requiring the front-end from doing the merging of these values; the front-end should be able to retrieve the final aggregated values in a single request.
+There are some ways which CouchDB could help us.
-One possible solution is to leverage the couchdb 'list' and 'show' features as described at http://wiki.apache.org/couchdb/Formatting_with_Show_and_List.  It may look something like:
+=== Better 'externals' support ===
-* We provide a number of different 'list' functions, each of which implement a different 'aggregation strategy' (eg, some schemas may want "give me all schemas with aggregated values", "give me only the schema with the highest confidence", etc.)
+Currently our API is implemented using a CouchDB 'external'.  It would be great if:
-* Depending on the specific schema being requested, a request is made to couch for a particular view, and specifying one of the list functions.
+* CouchDB allowed more than one request at a time.  Currently, requests are "queued" - so if our front-end issues 2 API requests simultaneously, one must wait until the other is complete before starting.  It appears as though one of the requests takes twice as long as it actually does.  This is reflected in a [https://issues.apache.org/jira/browse/COUCHDB-277 couchdb bug].
-* The list function will consume and process a number of rows, and emit a single aggregated row for that schema, with the exact contents of that row depending on the aggregation strategy implemented by that function.
+* Provide enough information so the external process can connect to the database "hosting" the external.  While the database name can be deduced, the address and port on which the database can be connected doesn't seem available.  This is being tracked in [https://issues.apache.org/jira/browse/COUCHDB-587 this bug]
-* The front-end sees only that single row with the values ready to be consumed.
+* Provide a facility to make it simpler to implement custom "entry point" scripts for couch_js.  This would allow us to implement our API (and possibly even back-end extensions) directly in JavaScript.  There was a problem in couch 0.10 which prevents this (curl support was broken), but 0.11 should make this easier.
 == Formal Schema Definitions ==