As I said a few days ago, I’ve been working on merging CouchCocoa into TouchDB. This makes its code simpler & faster because it can just call the internal TouchDB core directly instead of having to go through an internal REST API. While I was doing this I made other changes too such as:
• Changing the namespace prefix from “Couch” to “TD”
• Making nearly all the API calls synchronous (i.e. no more RESTOperation)
• Getting rid of the “design document” concept and exposing views directly
• Merging the two replication classes into one
This version will become TouchDB 1.1 or 2.0 or something (I haven’t decided on a version number yet!) but you can try it out now by checking out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on the wiki] that describes how to change your project and source code. There is a script included that helps with the ‘Couch’—>’TD’ renaming, but there’s more conversion that has to be done by hand. Hopefully it won’t be hard; I was able to convert Grocery Sync pretty quickly.
Converted apps appear to be about 300k smaller! I haven’t measured performance, but it should be better.
I’m interested to hear what people think of this. This is an opportunity to make incompatible changes to the API, so if there’s something that’s been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if you think any of the changes go in the wrong direction, let me know why.
One question: now that there's only one project, is it now easier to have the source code being built as part of the application, instead of loading the precompiled framework? Have you done it?
On Friday, November 9, 2012 4:44:42 PM UTC-6, Jens Alfke wrote:
> As I said a few days ago, I’ve been working on merging CouchCocoa into > TouchDB. This makes its code simpler & faster because it can just call the > internal TouchDB core directly instead of having to go through an internal > REST API. While I was doing this I made other changes too such as:
> • Changing the namespace prefix from “Couch” to “TD”
> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
> • Getting rid of the “design document” concept and exposing views directly
> • Merging the two replication classes into one
> This version will become TouchDB 1.1 or 2.0 or something (I haven’t > decided on a version number yet!) but you can try it out now by checking > out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” > branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on > the wiki] that describes how to change your project and source code. There > is a script included that helps with the ‘Couch’—>’TD’ renaming, but > there’s more conversion that has to be done by hand. Hopefully it won’t be > hard; I was able to convert Grocery Sync pretty quickly.
> Converted apps appear to be about 300k smaller! I haven’t measured > performance, but it should be better.
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
On Nov 10, 2012, at 8:25 AM, Eduardo Scoz <eduardos...@gmail.com<mailto:eduardos...@gmail.com>> wrote:
One question: now that there's only one project, is it now easier to have the source code being built as part of the application, instead of loading the precompiled framework? Have you done it?
I think that should work, though you’ll need to #include the TouchDB prefix header (.pch file) as part of your app’s prefix.
On Saturday, November 10, 2012 1:58:45 PM UTC-6, Jens Alfke wrote:
> On Nov 10, 2012, at 8:25 AM, Eduardo Scoz <eduar...@gmail.com<javascript:>> > wrote:
> One question: now that there's only one project, is it now easier to have > the source code being built as part of the application, instead of loading > the precompiled framework? Have you done it?
> I think that should work, though you’ll need to #include the TouchDB > prefix header (.pch file) as part of your app’s prefix.
On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
Hi, will features that rely on sending HTTP header requests i.e Issue #127 still be supported. If not then I'd like to see a direct API call to get the local path of an attachment.
On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
> As I said a few days ago, I’ve been working on merging CouchCocoa into > TouchDB. This makes its code simpler & faster because it can just call the > internal TouchDB core directly instead of having to go through an internal > REST API. While I was doing this I made other changes too such as:
> • Changing the namespace prefix from “Couch” to “TD”
> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
> • Getting rid of the “design document” concept and exposing views directly
> • Merging the two replication classes into one
> This version will become TouchDB 1.1 or 2.0 or something (I haven’t > decided on a version number yet!) but you can try it out now by checking > out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” > branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on > the wiki] that describes how to change your project and source code. There > is a script included that helps with the ‘Couch’—>’TD’ renaming, but > there’s more conversion that has to be done by hand. Hopefully it won’t be > hard; I was able to convert Grocery Sync pretty quickly.
> Converted apps appear to be about 300k smaller! I haven’t measured > performance, but it should be better.
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
On Nov 11, 2012, at 6:44 AM, Andrew Reslan <andrew.res...@mac.com> wrote:
> Hi, will features that rely on sending HTTP header requests i.e Issue #127 still be supported. If not then I'd like to see a direct API call to get the local path of an attachment.
Good point. I’m sure there are some holes like this in the new API — I hadn’t thought of the attachment-path header. I’ve just checked in a new property of TDAttachment to get the path. If you run into other missing bits, please file issues on them; they’re mostly going to be pretty trivial to add, I think.
On Sunday, November 11, 2012 2:20:43 PM UTC-8, Traun Leyden wrote:
> Very exciting news - can't wait to try it!
> On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
>> As I said a few days ago, I’ve been working on merging CouchCocoa into >> TouchDB. This makes its code simpler & faster because it can just call the >> internal TouchDB core directly instead of having to go through an internal >> REST API. While I was doing this I made other changes too such as:
>> • Changing the namespace prefix from “Couch” to “TD”
>> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
>> • Getting rid of the “design document” concept and exposing views directly
>> • Merging the two replication classes into one
>> This version will become TouchDB 1.1 or 2.0 or something (I haven’t >> decided on a version number yet!) but you can try it out now by checking >> out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” >> branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on >> the wiki] that describes how to change your project and source code. There >> is a script included that helps with the ‘Couch’—>’TD’ renaming, but >> there’s more conversion that has to be done by hand. Hopefully it won’t be >> hard; I was able to convert Grocery Sync pretty quickly.
>> Converted apps appear to be about 300k smaller! I haven’t measured >> performance, but it should be better.
>> I’m interested to hear what people think of this. This is an opportunity >> to make incompatible changes to the API, so if there’s something that’s >> been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if >> you think any of the changes go in the wrong direction, let me know why.
> (I'm building TouchDB as a framework and copying into my application > project)
> On Sunday, November 11, 2012 2:20:43 PM UTC-8, Traun Leyden wrote:
>> Very exciting news - can't wait to try it!
>> On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
>>> As I said a few days ago, I’ve been working on merging CouchCocoa into >>> TouchDB. This makes its code simpler & faster because it can just call the >>> internal TouchDB core directly instead of having to go through an internal >>> REST API. While I was doing this I made other changes too such as:
>>> • Changing the namespace prefix from “Couch” to “TD”
>>> • Making nearly all the API calls synchronous (i.e. no more >>> RESTOperation)
>>> • Getting rid of the “design document” concept and exposing views >>> directly
>>> • Merging the two replication classes into one
>>> This version will become TouchDB 1.1 or 2.0 or something (I haven’t >>> decided on a version number yet!) but you can try it out now by checking >>> out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” >>> branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on >>> the wiki] that describes how to change your project and source code. There >>> is a script included that helps with the ‘Couch’—>’TD’ renaming, but >>> there’s more conversion that has to be done by hand. Hopefully it won’t be >>> hard; I was able to convert Grocery Sync pretty quickly.
>>> Converted apps appear to be about 300k smaller! I haven’t measured >>> performance, but it should be better.
>>> I’m interested to hear what people think of this. This is an opportunity >>> to make incompatible changes to the API, so if there’s something that’s >>> been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if >>> you think any of the changes go in the wrong direction, let me know why.
On Nov 12, 2012, at 12:17 PM, Traun Leyden <traun.ley...@gmail.com<mailto:traun.ley...@gmail.com>> wrote:
I had to copy the following headers manually to get past some compile errors:
TDCache.h
MYDynamicObject.h
TDUITableSource.h
Oops! Sorry, that’s a problem that doesn’t show up when building a sample app that’s in the same project folder as the framework, since it can see all the project headers.
> On Monday, November 12, 2012 1:27:05 PM UTC-8, Jens Alfke wrote:
>> On Nov 12, 2012, at 12:24 PM, Traun Leyden <traun....@gmail.com> wrote:
>> Also how would this code get converted to the public-api branch?
>> There isn’t any direct access to the _changes feed in the new API, mostly >> because I didn’t think anyone would need it. What are you using it for?
>> On Monday, November 12, 2012 1:27:05 PM UTC-8, Jens Alfke wrote:
>>> On Nov 12, 2012, at 12:24 PM, Traun Leyden <traun....@gmail.com> wrote:
>>> Also how would this code get converted to the public-api branch?
>>> There isn’t any direct access to the _changes feed in the new API, >>> mostly because I didn’t think anyone would need it. What are you using it >>> for?
Interesting, look forward to trying this out! Any particular reason you got rid of the asynchronous APIs? I understand I can recreate a similar API easily on top of a synchronous API, but I quite like the "asynchronous by default" way that the CouchCocoa RESTOperation API has made me design stuff (only wait or add a completion handler when necessary).
On Friday, 9 November 2012 22:44:42 UTC, Jens Alfke wrote:
> As I said a few days ago, I’ve been working on merging CouchCocoa into > TouchDB. This makes its code simpler & faster because it can just call the > internal TouchDB core directly instead of having to go through an internal > REST API. While I was doing this I made other changes too such as:
> • Changing the namespace prefix from “Couch” to “TD”
> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
> • Getting rid of the “design document” concept and exposing views directly
> • Merging the two replication classes into one
> This version will become TouchDB 1.1 or 2.0 or something (I haven’t > decided on a version number yet!) but you can try it out now by checking > out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” > branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on > the wiki] that describes how to change your project and source code. There > is a script included that helps with the ‘Couch’—>’TD’ renaming, but > there’s more conversion that has to be done by hand. Hopefully it won’t be > hard; I was able to convert Grocery Sync pretty quickly.
> Converted apps appear to be about 300k smaller! I haven’t measured > performance, but it should be better.
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
On Nov 16, 2012, at 3:35 PM, Matias Piipari <matias.piip...@gmail.com<mailto:matias.piip...@gmail.com>> wrote:
Interesting, look forward to trying this out! Any particular reason you got rid of the asynchronous APIs?
Simpler implementation, primarily. Since the public API is now just calling native internal APIs rather than going through a REST/HTTP interface, it’s a lot easier if it can just call it directly. Otherwise I have to wrap dispatch_async around the insides of every public API call, allocate response/operation objects, etc. (This really adds up — an iOS app built with the new TouchDB appears to be ~300k smaller than one built with TouchDB 1.0 + CouchCocoa.)
Also, the CouchCocoa API wasn’t consistently asynchronous. Most of the higher level stuff ended up being synchronous, especially once you got to the model layer. So it’s a more consistent API design to give everything the same behavior.
Ok, understood, sounds sensible. I notice from the wiki that the HTTP
listener will still be available, and the use case of having a web view
talk to the database directly over HTTP is mentioned. This is a central use
case also for the Mac application I'm building. Just to check, is the
intention with this changed implementation also to still to allow also
replicating TouchDBs directly between each other without a CouchDB in
between?
On Sat, Nov 17, 2012 at 12:13 AM, Jens Alfke <j...@couchbase.com> wrote:
> On Nov 16, 2012, at 3:35 PM, Matias Piipari <matias.piip...@gmail.com>
> wrote:
> Interesting, look forward to trying this out! Any particular reason you
> got rid of the asynchronous APIs?
> Simpler implementation, primarily. Since the public API is now just
> calling native internal APIs rather than going through a REST/HTTP
> interface, it’s a lot easier if it can just call it directly. Otherwise I
> have to wrap dispatch_async around the insides of every public API call,
> allocate response/operation objects, etc. (This really adds up — an iOS app
> built with the new TouchDB appears to be ~300k smaller than one built with
> TouchDB 1.0 + CouchCocoa.)
> Also, the CouchCocoa API wasn’t consistently asynchronous. Most of the
> higher level stuff ended up being synchronous, especially once you got to
> the model layer. So it’s a more consistent API design to give everything
> the same behavior.
Papers - Your Personal Library of Science
Winner of the Apple Design Awards & Ars Design Award
Best Mac OS X Scientific Solution
http://mekentosj.com/papers
On Nov 16, 2012, at 4:23 PM, Matias Piipari <matias.piip...@gmail.com<mailto:matias.piip...@gmail.com>> wrote:
Just to check, is the intention with this changed implementation also to still to allow also replicating TouchDBs directly between each other without a CouchDB in between?
Yup, provided you link in the listener of course. (Basically the TDRouter class, which implements the REST API, has moved into the listener framework since the core TouchDB doesn’t need it anymore.)
On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
> As I said a few days ago, I’ve been working on merging CouchCocoa into > TouchDB. This makes its code simpler & faster because it can just call the > internal TouchDB core directly instead of having to go through an internal > REST API. While I was doing this I made other changes too such as:
> • Changing the namespace prefix from “Couch” to “TD”
> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
> • Getting rid of the “design document” concept and exposing views directly
> • Merging the two replication classes into one
> This version will become TouchDB 1.1 or 2.0 or something (I haven’t > decided on a version number yet!) but you can try it out now by checking > out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” > branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on > the wiki] that describes how to change your project and source code. There > is a script included that helps with the ‘Couch’—>’TD’ renaming, but > there’s more conversion that has to be done by hand. Hopefully it won’t be > hard; I was able to convert Grocery Sync pretty quickly.
> Converted apps appear to be about 300k smaller! I haven’t measured > performance, but it should be better.
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
> As I said a few days ago, I’ve been working on merging CouchCocoa into > TouchDB. This makes its code simpler & faster because it can just call the > internal TouchDB core directly instead of having to go through an internal > REST API. While I was doing this I made other changes too such as:
> • Changing the namespace prefix from “Couch” to “TD”
> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
> • Getting rid of the “design document” concept and exposing views directly
> • Merging the two replication classes into one
> This version will become TouchDB 1.1 or 2.0 or something (I haven’t > decided on a version number yet!) but you can try it out now by checking > out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” > branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on > the wiki] that describes how to change your project and source code. There > is a script included that helps with the ‘Couch’—>’TD’ renaming, but > there’s more conversion that has to be done by hand. Hopefully it won’t be > hard; I was able to convert Grocery Sync pretty quickly.
> Converted apps appear to be about 300k smaller! I haven’t measured > performance, but it should be better.
> I’m interested to hear what people think of this. This is an opportunity > to make incompatible changes to the API, so if there’s something that’s > been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if > you think any of the changes go in the wrong direction, let me know why.
On Wednesday, November 21, 2012 4:05:21 AM UTC+11, Traun Leyden wrote:
> Any ETA on when this will be merged into the stable release?
> (I realize this is a tough question, but just looking for a realistic > ballpark, eg, 1 mo, 3 mo, 6 mo..)
> On Friday, November 9, 2012 2:44:42 PM UTC-8, Jens Alfke wrote:
>> As I said a few days ago, I’ve been working on merging CouchCocoa into >> TouchDB. This makes its code simpler & faster because it can just call the >> internal TouchDB core directly instead of having to go through an internal >> REST API. While I was doing this I made other changes too such as:
>> • Changing the namespace prefix from “Couch” to “TD”
>> • Making nearly all the API calls synchronous (i.e. no more RESTOperation)
>> • Getting rid of the “design document” concept and exposing views directly
>> • Merging the two replication classes into one
>> This version will become TouchDB 1.1 or 2.0 or something (I haven’t >> decided on a version number yet!) but you can try it out now by checking >> out the “public-api<https://github.com/couchbaselabs/TouchDB-iOS/commits/public-api>” >> branch from Github. I’ve written a new document<https://github.com/couchbaselabs/TouchDB-iOS/wiki/Upgrading-From-Couc...> [on >> the wiki] that describes how to change your project and source code. There >> is a script included that helps with the ‘Couch’—>’TD’ renaming, but >> there’s more conversion that has to be done by hand. Hopefully it won’t be >> hard; I was able to convert Grocery Sync pretty quickly.
>> Converted apps appear to be about 300k smaller! I haven’t measured >> performance, but it should be better.
>> I’m interested to hear what people think of this. This is an opportunity >> to make incompatible changes to the API, so if there’s something that’s >> been bugging you about CouchCocoa, now’s the time to suggest a fix. Or if >> you think any of the changes go in the wrong direction, let me know why.
On Nov 20, 2012, at 9:05 AM, Traun Leyden <traun.ley...@gmail.com<mailto:traun.ley...@gmail.com>> wrote:
Any ETA on when this will be merged into the stable release?
(I realize this is a tough question, but just looking for a realistic ballpark, eg, 1 mo, 3 mo, 6 mo..)
I’m thinking of the new API as being part of a “1.1” or “1.5” type of release, i.e. the next major release. If you’re asking when that would ship, I’d guess 3-4 months would be the right ballpark.
