Internet library syntax discussion

[FourthWorld]

If all network I/O were non-blocking (add callbacks for POST) I won't care much what the syntax looks like, I'll just be happy. Seems I come across a request for a non-blocking POST almost once a month these days.

And I don't know if this is out of scope here, but it would be super-cool if LC could fork child processes in a way that lets us pass socket connections to them. With that we could not only support FastCGI, but also make all manner of efficient specialized app servers using faceless standalones.

[jacque]

I'm probably showing my ignorance here, but if all requests are nonblocking, how would we handle the cases where an app can't continue until the data is received?

[SparkOut]

By checking until the callback value is "complete" or appropriate.

[jacque]

By checking until the callback value is "complete" or appropriate.

Right, but the user can do all sorts of things while I'm waiting for that. Do I have to lock down every possible user action? In my current project they should not be able to click any buttons, type into any fields, or anything else until the data is retrieved. I want everything to be blocked until the server returns the data.

[FourthWorld]

At the risk of sounding like a cranky old man, I like the setup we have now where most Internet things can be called using blocking or non-blocking syntax options. It would be ideal if we could maintain both going forward.

[SparkOut]

Would that be as simple as defining every request without a callback as blocking, and every request with a callback as nonblocking?

[trevordevore]

Would that be as simple as defining every request without a callback as blocking, and every request with a callback as nonblocking?

That is what I was thinking. While I try not to use blocking calls in my apps because LiveCode doesn't respond well to resizing the stack and other events, they make testing and quick tools much easier. Callbacks require a lot more code but offer a better user experience.

[jacque]

Would that be as simple as defining every request without a callback as blocking, and every request with a callback as nonblocking?

That sounds like a workable approach to me. Then we have control.

[trevordevore]

The other thing to consider is how status is reported. Currently we parse headers to determine what the status code is. For headers we have libURLLastRHHeaders(). I think we should use the new approach that @LCMark has proposed (e.g. the message was handled), however. For example:

Code: Select all

the request error
the response header
the response status code
the response content type

Or maybe we treat the header as an object:

Code: Select all

the status code of the response header
the content type of the response header

An example:

Code: Select all

put url request "http://livecode.com" with headers tHeaders into tReturnedData
if the request error is not empty then
   switch the last response code
      case "404"
         ...
         break 
      case "401"
         ...
         break
      case empty
         -- no response received, error happened before server could respond.
         break
      default
         ...
   end switch
end if

[trevordevore]

I neglected to mention that we need a way of getting a unique ID for async network operations. This allows us to cancel it if need be. Something like this:

Code: Select all

request url "http://livecode.com" with callback "MyCallback"
put the request id into sLastURLRequestId
cancel url request sLastURLRequestId