Strategy with Network and File I/O moving forwards

William Prothero prothero at earthednet.org
Wed May 6 10:52:31 EDT 2015


David:
Thanks for addressing this. It looks like those trying to implement these protocols go through enough agony, and the need is strong enough so that a better support system is needed.
Thanks again,
Bill 

William A. Prothero
http://es.earthednet.org/

> On May 6, 2015, at 1:42 AM, David Bovill <david at viral.academy> wrote:
> 
> The blocking aspects of some of then http calls - the documentation and
> issues around the lack of some REST capbabilities, and then quirks with
> working with http and related protocols in the wild make me think that the
> strategy of relying simply on socket primitives and getting the mothership
> or Livecode community to write robust basic http libraries is not working.
> 
> Now that LiveCode is open source, what would the best strategy be with
> regard to implementing robust cross-platform http / multiprotocol internet
> functionality? My guess is that LiveCode Ltd business strategy would
> require a liberal license.
> 
> C and C++ CURL libraries seem to be the way to go? This could (depending on
> the imlementation) have the advantage of all those curl related examples
> for REST API's working out of the box.
> 
>   -
>   http://stackoverflow.com/questions/822581/what-c-library-should-i-use-to-implement-a-http-client#822591
>   - http://sourceforge.net/projects/curlpp/
>   - http://curl.haxx.se/
>   - https://github.com/bagder/curl
> 
> Is it the case that what we as a community are aiming for here is to answer
> the sort of question posed above with - wrap this in a community generated
> Livecode Builder library, and let the mothership get on with delivering on
> the Kickstarter goals?
> 
> So is it a good idea to implement a curl based Livecode library in the
> present state of Livecode builder?
> 
> 
> On 6 May 2015 at 03:43, J. Landman Gay <jacque at hyperactivesw.com> wrote:
> 
>> On May 5, 2015 6:17:48 PM CDT, Trevor DeVore <lists at mangomultimedia.com>
>> wrote:
>>> On Tuesday, May 5, 2015, Dave Cragg <dave.cragg at lacscentre.co.uk>
>>> wrote:
>>>> 
>>>> 
>>>> From memory, I think the size of each chunk is sent with each chunk
>>> itself
>>>> in the message portion of the reply, not in the headers.
>>> 
>>> 
>>> Ah, that would explain it.
>>> 
>>> libUrl should deal with this. It’s a fairly common transfer method.
>>> (Sorry,
>>>> Jacque, I know that doesn’t help you.)
>>>> 
>>> 
>>> Yes, the code is in there to deal with it.
>>> 
>>> I have seen similar problem when interacting with wordpress. There are
>>> plug-ins that mess up the headers for the XML RPC requests. Livecode
>>> never
>>> thinks it is done getting data because the content length header is not
>>> accurate.  Seeing as this problem occurred after an upgrade on the
>>> server
>>> the content size information seems like a possible a cause.
>> 
>> I agree. I compared the headers that work with the ones that don't, and
>> the working transmissions do include a content length header. There must be
>> a difference in how the data is being sent. We'll probably do some testing
>> tomorrow. But if libURL handles chunks you'd think those headers would
>> work. Browsers have no trouble with retrieval when we call the URL from
>> there. It's only LiveCode.
>> 
>> Really appreciate this discussion, the problem has been a difficult one
>> for us.
>> --
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode




More information about the use-livecode mailing list