Making things convenient broke concurrency

[cinayakoshka]

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?

[ntoll]

Hey Bar,

In the JS library we just pass in a flag to the function that makes the call to indicate if it is to be asynchronous (the default) or not (you have to be explicit). This has the advantage of there only being one function and the default behaviour is async.

Not sure how that would translate to Obj-C though.

N.

[cinayakoshka]

Yeah, I wish we could do that without shackling our users to whatever concurrency model I choose.
That's not a good solution, here, because asynchronously executed items can be augmented with useful features in Obj-C, like dependencies and timeouts. If I execute them asynchronously, that leaves users unable to use those features.

[cinayakoshka]

I'm pretty sure I'm just going to throw out the synchronous convenience methods that gridaphobe asked for, basically going back to where we started, in which, to run a request synchronously, one could use the convenience method in session:
ServerResponse *response = [Session doRequest [_session put: ...] ];

Sorry, gridaphobe. It's really the best way for me to offer the most flexible solution to people writing asynchronous applications. That humungous branch? Complete waste of time, and my fault, too, because I knew that I had made that design decision for a good reason in the first place.