Page 2 of 2
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 3:24 pm
by 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.
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 6:21 pm
by 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?
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 7:03 pm
by SparkOut
By checking until the callback value is "complete" or appropriate.
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 8:06 pm
by jacque
SparkOut wrote: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.
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 9:18 pm
by 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.
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 11:14 pm
by SparkOut
Would that be as simple as defining every request without a callback as blocking, and every request with a callback as nonblocking?
Re: Internet library syntax discussion
Posted: Mon Jun 08, 2015 11:36 pm
by trevordevore
SparkOut wrote: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.
Re: Internet library syntax discussion
Posted: Tue Jun 09, 2015 7:52 pm
by jacque
SparkOut wrote: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.
Re: Internet library syntax discussion
Posted: Mon Jun 15, 2015 11:14 pm
by 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
Re: Internet library syntax discussion
Posted: Fri Jul 03, 2015 9:16 pm
by 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