igorski89 / couchbase-lite-ios Goto Github PK

relative "enhancement": CBLSocketChangeTracker uses YAJL as streaming JSON parser. The issue is that old erlang-based Couchbase.framework uses the same library and unfortunately both cannot be used in the same address space.

This means that I need to revert implementation to use non-streaming parser implementation from old TouchDB.

The plan:

1. rename CBLSocketChangeTracker to CBLSocketStreamingChangeTracker
2. import TDConnectionChangeTracker and refactor to CBLConnectionChangeTracker
3. same with TDSocketChangeTracker
4. refactor CBLChangeTracker to provide receivedChanges:errorMessage: and receivedChange: methods
5. refactor CBLChangeTracker constructor:
   • if CBLSocketStreamingChangeTracker class exist – use it
   • if normal changes feed – use TDConnectionChangeTracker
   • if continuos or longpoll – use TDSocketChangeTracker

http://couchdb.readthedocs.org/en/latest/couchapp/ddocs.html?highlight=_count

in addition to #3 list functions should have access to start() and send() functions in order to be able to send chunked responses.

Obviously since we don't have/really need this functionality in mobile, we will just emulate it with response object, because this is how the most list functions are written

http://docs.couchdb.org/en/latest/json-structure.html#response-object

Probably means that CBLShowFunctionResult and CBLListFunctionResult classes needs to be removed and new class CBLResponseObject used instead.

Request object is passed to the show/list function, currently it's being poorly constructed manually https://github.com/evsukov89/couchbase-lite-ios/blob/jsddoc/Source/CBL_Router%2BHandlers.m#L1137-L1141 but it should be done according to a documentation http://docs.couchdb.org/en/latest/json-structure.html#request-object

because otherwise if one replication must validate it and other replication must not - we have a mess

Checkpoint documents _local/<replication_id> are stored on remote database. This could be an issue if remote database is read-only. Storing checkpoint documents on local db will also improve replication start speed because it won't need perform remote request.

This makes sense with native functions, because in that case you need to explicitly specify version, but in case of js functions from design documents, they will never be invalidated.

Caching via $name-$_rev should do the trick. Alternatively, we can use MD5 from function's source code.

http://docs.couchdb.org/en/latest/query-servers.html#provides

• JSON – supported by default in JavaScriptCore
• isArray()
• log()
• require() – seems like it's not implemented in JSC
• sum()
• toJSON()

For now – iOS7 only via linking with JavaScriptCore.framework, later on – provide the same functionality for iOS5-6 using custom compiled library https://github.com/phoboslab/JavaScriptCore-iOS