On Friday, August 7, 2015 at 11:06:10 AM UTC-7, Jens Alfke wrote: > > > On Aug 7, 2015, at 10:08 AM, Brett Harrison <brett.h...@zyamusic.com > <javascript:>> wrote: > > I submitted the C# pull request. I believe I could alter my API to more > closely match yours from what I have seen. I would most likely wait until > yours is more finalized. > > > Hi Brett! That sounds great. > > Currently the major differences that I have vs. you features are: > - I don't currently expose a progress callback > > > I assumed that the ‘Task’ object, returned from your public method that > starts the download, includes a way for the app to monitor progress. > (There’s a similar Cocoa class called NSProgress which I’m thinking of > using.) I’m not familiar with the .NET frameworks and I assume it’s a > standard class? >
The Task object is basically a Job for a thread pool. If I convert to your API, it would be removed. I do have a progress callback internally, but I didn't expose it because: - It would have to work properly with combined requests - I was undecided if it should include the data stream - We didn't need it yet > > - I do combine requests that would pull the same object based on the > digest (so only one network request would be made) > > > Yup, I’ll be adding that. > > - I throttle the number of simultaneous network requests to 4 > (configurable), so that the network does not get choked with too many > requests at once. > > > The Cocoa network framework already takes care of that; like a browser, it > will open a limited number of sockets to a single host, and queues requests > onto those sockets. > > - I created a new replication "AttachmentPuller" to do this work instead > of adding to the current Puller. > > > I didn’t see a need to change the public API to do this. The app should be > able to use the same Replication it already uses to pull docs. It’s fine to > use a new puller object internally, but that should be just an > implementation detail. > I may be able to merge the AttachmentPull back into the normal Puller, I just want to be able to make a Puller that only does attachments. I don't want to have to call Start on it because I don't want it to try to sync the documents ever (I have another puller for that). I plan to have the attachment puller point at a different URL that is a CDN (the CDN will pull from the original sync gateway as needed). Anyway, I will take a look at eliminating the AttachmentPuller to keep the APIs the same. > > > I’m currently working on making it possible to resume interrupted > downloads. This requires extending Sync Gateway to support “Range:” headers > on requests for attachments; I’ve got that mostly complete. > > Also, I found that when a response has “Content-Encoding: gzip” — as with > an attachment that was originally stored in compressed form — there’s no > way to prevent Cocoa’s NSURLConnection from unzipping the body. This is a > problem since the attachment needs to be stored as-is, otherwise the digest > breaks. I’m adding a “?content_encoding=false” query option to Sync > Gateway’s attachment handler to disable using Content-Encoding for this; > instead it’ll set the Content-Type to “application/gzip”. > > —Jens > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchbase+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/bc5c8176-0e40-4212-8b61-9c2061ed2f3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
