On May 15, 2012, at 02:22 PM, Jens Alfke <j...@mooseyard.com> wrote:
On May 15, 2012, at 12:56 PM, Alex Zavatone wrote: We are caching (saving in a pList) the data from the previous launch. It falls through and uses the previously saved data if we can't get to the internet. Now, what I'm unclear on at this point (I've never truly truly trusted some system to cache stuff for me) is how the system knows if the data online is newer than the data we've got. I trust that the caching method you're mentioning is different than saving to a pList? It looks like this: * Read data from plist if present * If you have data, display it * Send an async HTTP GET to the data source URL. If you already have cached data, get the cached Etag value (q.v.) and add it as the value of an If-None-Match: header. * Start the event loop. … * When a response arrives: * If the status is 304, it means there is no newer data on the server. * If the status is not 200, there was an error. * Otherwise update the UI with the new data. * Save the new data to the plist on disk. * Also save the value of the “Etag” header from the response, so you can send it with the next request. This is called a “Conditional GET”. It’s a key part of the way the Web does caching. Browsers use it, news readers use it, REST APIs use it. There are a lot of online references; here’s one from the Google search results that looks decent: https://ruturajv.wordpress.com/2005/12/27/conditional-get-request/ Rockin'. Exactly the information I was looking for. My only other question is what's the "best" approach for async requests? I've used GCD recently, but it appears that the frameworks have been advancing so quickly, it's not always obvious what the current best method is for async HTTP communication. It's been about 14 years since I've written an async network operation manager, one does get rusty. ...OK, I just located the document I’ve been trying to find since this thread started. In terms of this, you’re hitting myths #1 and #2: These are DIRECTLY relevant to my next project, where I can be assured that the connection health and speed will be variable. You're on either my Christmas list or in my will. Please pick only one. The Eight Myths Of Distributed Computing, by Peter Deutsch Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences. 1.The network is reliable 2.Latency is zero 3.Bandwidth is infinite 4.The network is secure 5.Topology doesn't change 6.There is one administrator 7.Transport cost is zero 8.The network is homogeneous http://nighthacks.com/roller/jag/resource/Fallacies.html —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
