fluidinfo/objc-client — Issue #24: Making things convenient broke concurrency - please advise
Author: cinayakoshka
Created: 2011-10-18 13:15:52+00:00
State: open

The fix I did some time ago that made lots of method calls convenient (by actually executing them instead of just preparing them) broke concurrency. It turns out that the synchronous networking call function demands to run in the main thread. I found this out as I attempted to make my iPad app concurrent, yesterday. So, there has got to be some middle ground. I think writing two versions of doRequest, one of which is asynchronous and uses a Session-specific NSOperationsQueue, would be all right, BUT, some developers will want to make some operations in another queue (and possibly another kind of queue!) depend on the results of these requests, and it would be nicer for them if they were permitted to handle the request-execution.

Maybe the right solution is to (and this is the advantage of having almost no users) undo the changes that we made for gridaphobe (sorry, dude!), and wrap up a new function called handleRequest, which will be just another convenience function for interpreting and wrapping up the server's response, intended to be passed as part of an upon-completion block with an NSOperation or similar mechanism. Additionally, I could make appropriately-named aliases for the convenient but synchronous functions (i.e., synchronouslyPut: ...) that we are now using. This would be nice because it would let people try out Fluidinfo via Obj-C without putting too much thought or care into low-level details. However, it would encourage lazy Lion devs to write non-concurrent code, which might indirectly make Fluidinfo look bad.

Opinions?