Re: Not sure what to do.....can I run this by you guys?

2018-03-18 Thread Tom Glod via use-livecode
Hi everyone here is the github repo for the stack demonstrating the
solution.  May not work on all cases but can for many.  Seems to work very
well for my needs. 10 requests ...no problem. have not done more.

https://github.com/makeshyft-tom-g/lc-single-domain-asynchronous-http

On Sun, Mar 18, 2018 at 11:54 PM, Tom Glod  wrote:

> Yup, realized that when I thought about and tried mikes suggestion
>
> Yes using a ? works just the same as # but may be safer in some way..
>
> I'm just completing demo stack for this .works flawlessly.
>
> Thanks to everyone who chimed in here to help me find solution...hopefully
> i can make it easier on others to publish a demo stack.
>
>
>
>
> On Sun, Mar 18, 2018 at 10:39 AM, Ben Rubinstein via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> I think this depends on the base URL.  If it's with a simple URL, there's
>> no reason why an appended '#' parameter should cause a browser to request
>> it fresh; as Mike says, it indicates scrolling to an anchor in the page. So
>> it's perfectly reasonable for a smart browser - or a caching layer on the
>> server, or in a proxy somewhere between you and the server - to use a
>> cached version of that page ignoring the '#' suffix.
>>
>> With a simple URL, the better choice is to use "?" to append a parameter
>> (I usually use 'the milliseconds' to guarantee that it's unique). Neither
>> the browser nor any caching layer on the chain between the user agent and
>> the source system should recognise it as the same URL, so this should force
>> a fresh load. You can just use e.g.
>> put "?" & the milliseconds after tURL
>>
>> or to be more explicit, name the parameter something e.g.
>> put "?nocache=" & the milliseconds after tURL
>> or
>>
>> put "?uniqueid=" & the milliseconds after tURL
>>
>> The only downside of using "?" is that if the URL may already includes
>> parameters starting with "?" (which is what I mean by "not a simple URL"),
>> you need to test for that and use "&" instead of "?" to indicate that this
>> is an additional parameter; and if this is a dynamic request, which uses
>> the 'query parameters' in the URL to decide what to return, you need to be
>> sure that adding your parameter won't affect it!
>>
>>
>> On 16/03/2018 13:31, Mike Bonner via use-livecode wrote:
>>
>>> Another way around the cache problem is to use the #2 trick at the end of
>>> the url.  Send each request with a pound and different number at the end
>>> of
>>> the url and it'll be seen as a new request thus doing an end run around
>>> the
>>> cache.  Since it designates an inline anchor position on the page, it
>>> should have zero affect on the way the url functions.  (unless things
>>> have
>>> changed, the associated anchor doesn't need to exist on the page)
>>>
>>> Thanks for the neat trick Charles. :)
>>>
>>> On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> WowI'm impressedthats quite a hack Charles..I will study all this
 see how far I get.

 Thank you gentlemenyou are Rockstars!!

 On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
 use-livecode@lists.runrev.com> wrote:

 Maybe not 100% reliable but 
>
> https://stackoverflow.com/questions/1341089/using-meta-
> tags-to-turn-off-caching-in-all-browsers
>
> Regards Lagi
>
> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
>  wrote:
>
>>   Hi Tom,
>>
>> If the site you are trying to contact has CORS enabled appropriately,
>>
> then you can do something like this...
>
>>
>> With the LiveCode browser widget, you can call JavaScript functions
>>
> from

> LC script and have the JavaScript functions call LC handlers in return.
> JavaScript has the capability to perform asynchronous HTTP requests.
>
>>
>> You can create a HTML page that you automatically load up in the
>>
> browser

> widget that has a small JavaScript function which you can call from LC
>
 with

> ‘do in widget’.   All this function needs to do is issue an
> asynchronous
> HTTP call to the URL passed to it as a parameter and when it receives
> the
> data, return it back to your LC script by calling a nominated LC
> handler
> and passing the returned data as a parameter.
>
>>
>> The HTML page would look something like this:
>>
>> 
>> 
>> Javascript Async Test
>> 
>>
>> function httpGetAsync(theUrl)
>> {
>>  var xmlHttp = new XMLHttpRequest();
>>  xmlHttp.onreadystatechange = function() {
>>  if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
>>  liveCode.httpRequestComplete(theUrl,
>>
> xmlHttp.responseText);

>  }
>>  xmlHttp.open("GET", 

Re: Not sure what to do.....can I run this by you guys?

2018-03-18 Thread Tom Glod via use-livecode
Yup, realized that when I thought about and tried mikes suggestion

Yes using a ? works just the same as # but may be safer in some way..

I'm just completing demo stack for this .works flawlessly.

Thanks to everyone who chimed in here to help me find solution...hopefully
i can make it easier on others to publish a demo stack.




On Sun, Mar 18, 2018 at 10:39 AM, Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I think this depends on the base URL.  If it's with a simple URL, there's
> no reason why an appended '#' parameter should cause a browser to request
> it fresh; as Mike says, it indicates scrolling to an anchor in the page. So
> it's perfectly reasonable for a smart browser - or a caching layer on the
> server, or in a proxy somewhere between you and the server - to use a
> cached version of that page ignoring the '#' suffix.
>
> With a simple URL, the better choice is to use "?" to append a parameter
> (I usually use 'the milliseconds' to guarantee that it's unique). Neither
> the browser nor any caching layer on the chain between the user agent and
> the source system should recognise it as the same URL, so this should force
> a fresh load. You can just use e.g.
> put "?" & the milliseconds after tURL
>
> or to be more explicit, name the parameter something e.g.
> put "?nocache=" & the milliseconds after tURL
> or
>
> put "?uniqueid=" & the milliseconds after tURL
>
> The only downside of using "?" is that if the URL may already includes
> parameters starting with "?" (which is what I mean by "not a simple URL"),
> you need to test for that and use "&" instead of "?" to indicate that this
> is an additional parameter; and if this is a dynamic request, which uses
> the 'query parameters' in the URL to decide what to return, you need to be
> sure that adding your parameter won't affect it!
>
>
> On 16/03/2018 13:31, Mike Bonner via use-livecode wrote:
>
>> Another way around the cache problem is to use the #2 trick at the end of
>> the url.  Send each request with a pound and different number at the end
>> of
>> the url and it'll be seen as a new request thus doing an end run around
>> the
>> cache.  Since it designates an inline anchor position on the page, it
>> should have zero affect on the way the url functions.  (unless things have
>> changed, the associated anchor doesn't need to exist on the page)
>>
>> Thanks for the neat trick Charles. :)
>>
>> On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>> WowI'm impressedthats quite a hack Charles..I will study all this
>>> see how far I get.
>>>
>>> Thank you gentlemenyou are Rockstars!!
>>>
>>> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>>
>>> Maybe not 100% reliable but 

 https://stackoverflow.com/questions/1341089/using-meta-
 tags-to-turn-off-caching-in-all-browsers

 Regards Lagi

 On 16 March 2018 at 09:48, Charles Warwick via use-livecode
  wrote:

>   Hi Tom,
>
> If the site you are trying to contact has CORS enabled appropriately,
>
 then you can do something like this...

>
> With the LiveCode browser widget, you can call JavaScript functions
>
 from
>>>
 LC script and have the JavaScript functions call LC handlers in return.
 JavaScript has the capability to perform asynchronous HTTP requests.

>
> You can create a HTML page that you automatically load up in the
>
 browser
>>>
 widget that has a small JavaScript function which you can call from LC

>>> with
>>>
 ‘do in widget’.   All this function needs to do is issue an asynchronous
 HTTP call to the URL passed to it as a parameter and when it receives
 the
 data, return it back to your LC script by calling a nominated LC handler
 and passing the returned data as a parameter.

>
> The HTML page would look something like this:
>
> 
> 
> Javascript Async Test
> 
>
> function httpGetAsync(theUrl)
> {
>  var xmlHttp = new XMLHttpRequest();
>  xmlHttp.onreadystatechange = function() {
>  if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
>  liveCode.httpRequestComplete(theUrl,
>
 xmlHttp.responseText);
>>>
  }
>  xmlHttp.open("GET", theUrl, true); // true for asynchronous
>  xmlHttp.send(null);
> }
> 
> 
> 
> 
> 
>
> You can either load that from a file into the browser widget’s URL or
>
 set its htmlText property accordingly...

>
> Then in LC, make sure you register the httpRequestComplete handler so
>
 that the widget can call it:

>
> set the javascriptHandlers of widget “browser” to “httpRequestComplete”
>
> After that, add a 

Re: Not sure what to do.....can I run this by you guys?

2018-03-18 Thread Ben Rubinstein via use-livecode
I think this depends on the base URL.  If it's with a simple URL, there's no 
reason why an appended '#' parameter should cause a browser to request it 
fresh; as Mike says, it indicates scrolling to an anchor in the page. So it's 
perfectly reasonable for a smart browser - or a caching layer on the server, 
or in a proxy somewhere between you and the server - to use a cached version 
of that page ignoring the '#' suffix.


With a simple URL, the better choice is to use "?" to append a parameter (I 
usually use 'the milliseconds' to guarantee that it's unique). Neither the 
browser nor any caching layer on the chain between the user agent and the 
source system should recognise it as the same URL, so this should force a 
fresh load. You can just use e.g.

put "?" & the milliseconds after tURL

or to be more explicit, name the parameter something e.g.
put "?nocache=" & the milliseconds after tURL
or

put "?uniqueid=" & the milliseconds after tURL

The only downside of using "?" is that if the URL may already includes 
parameters starting with "?" (which is what I mean by "not a simple URL"), you 
need to test for that and use "&" instead of "?" to indicate that this is an 
additional parameter; and if this is a dynamic request, which uses the 'query 
parameters' in the URL to decide what to return, you need to be sure that 
adding your parameter won't affect it!


On 16/03/2018 13:31, Mike Bonner via use-livecode wrote:

Another way around the cache problem is to use the #2 trick at the end of
the url.  Send each request with a pound and different number at the end of
the url and it'll be seen as a new request thus doing an end run around the
cache.  Since it designates an inline anchor position on the page, it
should have zero affect on the way the url functions.  (unless things have
changed, the associated anchor doesn't need to exist on the page)

Thanks for the neat trick Charles. :)

On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:


WowI'm impressedthats quite a hack Charles..I will study all this
see how far I get.

Thank you gentlemenyou are Rockstars!!

On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:


Maybe not 100% reliable but 

https://stackoverflow.com/questions/1341089/using-meta-
tags-to-turn-off-caching-in-all-browsers

Regards Lagi

On 16 March 2018 at 09:48, Charles Warwick via use-livecode
 wrote:

  Hi Tom,

If the site you are trying to contact has CORS enabled appropriately,

then you can do something like this...


With the LiveCode browser widget, you can call JavaScript functions

from

LC script and have the JavaScript functions call LC handlers in return.
JavaScript has the capability to perform asynchronous HTTP requests.


You can create a HTML page that you automatically load up in the

browser

widget that has a small JavaScript function which you can call from LC

with

‘do in widget’.   All this function needs to do is issue an asynchronous
HTTP call to the URL passed to it as a parameter and when it receives the
data, return it back to your LC script by calling a nominated LC handler
and passing the returned data as a parameter.


The HTML page would look something like this:



Javascript Async Test


function httpGetAsync(theUrl)
{
 var xmlHttp = new XMLHttpRequest();
 xmlHttp.onreadystatechange = function() {
 if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
 liveCode.httpRequestComplete(theUrl,
xmlHttp.responseText);
 }
 xmlHttp.open("GET", theUrl, true); // true for asynchronous
 xmlHttp.send(null);
}






You can either load that from a file into the browser widget’s URL or

set its htmlText property accordingly...


Then in LC, make sure you register the httpRequestComplete handler so

that the widget can call it:


set the javascriptHandlers of widget “browser” to “httpRequestComplete”

After that, add a httpRequestComplete handler to the card script to

handle the returned data:


on httpRequestComplete pUrl, pData
— pUrl will be the URL requested
— pData will be the data returned from the URL requested
end httpRequestComplete

Lastly, make your async requests

do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”

Since the JavaScript in the browser widget is issuing the requests and

sending the data back to LC, it doesn’t need to display anything related

to

it in the browser widget itself - it can be a blank canvas.


Just be aware that the browser widget can cache URLs and there is no

easy way (that I know of?) in LC to clear the browser’s cache... 

Re: Not sure what to do.....can I run this by you guys?

Just remember the browser widget in LiveCode uses CEF (Chromium Embedded 
Framework) on all platforms.

It doesn’t need to work on Safari or Firefox.

> On 17 Mar 2018, at 1:40 am, Tom Glod via use-livecode 
>  wrote:
> 
> this solution has to work flawlessly in production on all 3 desktop
> platforms.
> 
> I'm giving a shot to modifying LibURL. I wish I knew why the limit is
> in there to begin with, that would help to know if I am wasting my time or
> not.
> 
> Realistically if it was as easy as just hacking that code, someone would
> have done it already.
> 
> Its fun anywaysI have to solve this...even if I speed it up just a
> little bit ..
> 
> Its not an emergency situation so its a fun problem to think about until
> its solved.
> 
> some good ideas from you guys thanks everyone
> 
> On Fri, Mar 16, 2018 at 11:31 AM, Mike Bonner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Yeah, thats what I was talking about, but I never tried it with safari i'm
>> afraid. Sounds like something funky with safari, though i'm not sure why my
>> method wouldn't work unless safari is smart enough now to recognize an
>> inline link and NOT treat it as a new URL to cache.
>> 
>> If this is only for your personal use, you can disable caching on safari as
>> described here: https://www.technipages.com/apple-safari-completely-
>> disable-cache
>> If you have safari 11, check here instead to disable cache:
>> https://stackoverflow.com/questions/46324675/how-do-
>> i-disable-cache-in-safari-11-0
>> 
>> If this is for an app being shipped though thats not a solution.  You said
>> firefox works fine, so i'm guessing you don't have some type of caching
>> proxy between you and the server.  Either way, from what I've been reading
>> just now, rather than using meta tags, you're more likely to get the
>> desired result if you set the headers directly.  One way to do this would
>> be with an .htaccess file.
>> https://stackoverflow.com/questions/11532636/how-to-
>> prevent-http-file-caching-in-apache-httpd-mamp
>> You'd need to add .lc to the filesmatch so that they're not cached.
>> 
>> Hopefully the correct module is installed. If it isn't, while I've never
>> done it, I believe you can set the headers to return using lc in your
>> server script (assuming you're using lc.) I know php can.  If you're using
>> something other than apache of course, ignore the above.
>> 
>> On Fri, Mar 16, 2018 at 8:53 AM, Rick Harrison via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Hi Mike,
>>> 
>>> I am finding that Safari is not honoring
>>> the meta tag to turn off caching.  I thought
>>> I would give your method a try.  I’m not
>>> sure I am doing it right though because
>>> that isn’t working either.
>>> 
>>> (Firefox does everything properly.)
>>> 
>>> I was thinking from your description that
>>> it would look something like:
>>> 
>>> http://www.yourwebsite.com/coolpage.lc#48432 <
>> http://www.yourwebsite.com/
>>> coolpage.lc#48432>
>>> 
>>> Is the above example of what you are discussing
>>> correct?  If not could you please post an example?
>>> 
>>> Thanks,
>>> 
>>> Rick
>>> 
 On Mar 16, 2018, at 9:31 AM, Mike Bonner via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Another way around the cache problem is to use the #2 trick at the end
>> of
 the url.  Send each request with a pound and different number at the
>> end
>>> of
 the url and it'll be seen as a new request thus doing an end run around
>>> the
 cache.  Since it designates an inline anchor position on the page, it
 should have zero affect on the way the url functions.  (unless things
>>> have
 changed, the associated anchor doesn't need to exist on the page)
 
 Thanks for the neat trick Charles. :)
 
 On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> WowI'm impressedthats quite a hack Charles..I will study all
>>> this
> see how far I get.
> 
> Thank you gentlemenyou are Rockstars!!
> 
> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Maybe not 100% reliable but 
>> 
>> https://stackoverflow.com/questions/1341089/using-meta-
>> tags-to-turn-off-caching-in-all-browsers
>> 
>> Regards Lagi
>> 
>> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
>>  wrote:
>>> Hi Tom,
>>> 
>>> If the site you are trying to contact has CORS enabled
>> appropriately,
>> then you can do something like this...
>>> 
>>> With the LiveCode browser widget, you can call JavaScript functions
> from
>> LC script and have the JavaScript functions call LC handlers in
>> return.
>> JavaScript has the capability to perform asynchronous HTTP requests.
>>> 
>>> You can 

Re: Not sure what to do.....can I run this by you guys?

Hi Mike,

I am in a testing phase right now for deployment
to others later, so disabling safari for myself isn’t
going to accomplish much.

I will look into setting the headers directly.

Thanks,

Rick

> On Mar 16, 2018, at 11:31 AM, Mike Bonner via use-livecode 
>  wrote:
> 
> Yeah, thats what I was talking about, but I never tried it with safari i'm
> afraid. Sounds like something funky with safari, though i'm not sure why my
> method wouldn't work unless safari is smart enough now to recognize an
> inline link and NOT treat it as a new URL to cache.
> 
> If this is only for your personal use, you can disable caching on safari as
> described here: https://www.technipages.com/apple-safari-completely-
> disable-cache
> If you have safari 11, check here instead to disable cache:
> https://stackoverflow.com/questions/46324675/how-do-
> i-disable-cache-in-safari-11-0
> 
> If this is for an app being shipped though thats not a solution.  You said
> firefox works fine, so i'm guessing you don't have some type of caching
> proxy between you and the server.  Either way, from what I've been reading
> just now, rather than using meta tags, you're more likely to get the
> desired result if you set the headers directly.  One way to do this would
> be with an .htaccess file.
> https://stackoverflow.com/questions/11532636/how-to-prevent-http-file-caching-in-apache-httpd-mamp
> You'd need to add .lc to the filesmatch so that they're not cached.
> 
> Hopefully the correct module is installed. If it isn't, while I've never
> done it, I believe you can set the headers to return using lc in your
> server script (assuming you're using lc.) I know php can.  If you're using
> something other than apache of course, ignore the above.
> 
> On Fri, Mar 16, 2018 at 8:53 AM, Rick Harrison via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi Mike,
>> 
>> I am finding that Safari is not honoring
>> the meta tag to turn off caching.  I thought
>> I would give your method a try.  I’m not
>> sure I am doing it right though because
>> that isn’t working either.
>> 
>> (Firefox does everything properly.)
>> 
>> I was thinking from your description that
>> it would look something like:
>> 
>> http://www.yourwebsite.com/coolpage.lc#48432 > coolpage.lc#48432>
>> 
>> Is the above example of what you are discussing
>> correct?  If not could you please post an example?
>> 
>> Thanks,
>> 
>> Rick
>> 
>>> On Mar 16, 2018, at 9:31 AM, Mike Bonner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> Another way around the cache problem is to use the #2 trick at the end of
>>> the url.  Send each request with a pound and different number at the end
>> of
>>> the url and it'll be seen as a new request thus doing an end run around
>> the
>>> cache.  Since it designates an inline anchor position on the page, it
>>> should have zero affect on the way the url functions.  (unless things
>> have
>>> changed, the associated anchor doesn't need to exist on the page)
>>> 
>>> Thanks for the neat trick Charles. :)
>>> 
>>> On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>>> 
 WowI'm impressedthats quite a hack Charles..I will study all
>> this
 see how far I get.
 
 Thank you gentlemenyou are Rockstars!!
 
 On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
 use-livecode@lists.runrev.com> wrote:
 
> Maybe not 100% reliable but 
> 
> https://stackoverflow.com/questions/1341089/using-meta-
> tags-to-turn-off-caching-in-all-browsers
> 
> Regards Lagi
> 
> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
>  wrote:
>> Hi Tom,
>> 
>> If the site you are trying to contact has CORS enabled appropriately,
> then you can do something like this...
>> 
>> With the LiveCode browser widget, you can call JavaScript functions
 from
> LC script and have the JavaScript functions call LC handlers in return.
> JavaScript has the capability to perform asynchronous HTTP requests.
>> 
>> You can create a HTML page that you automatically load up in the
 browser
> widget that has a small JavaScript function which you can call from LC
 with
> ‘do in widget’.   All this function needs to do is issue an
>> asynchronous
> HTTP call to the URL passed to it as a parameter and when it receives
>> the
> data, return it back to your LC script by calling a nominated LC
>> handler
> and passing the returned data as a parameter.
>> 
>> The HTML page would look something like this:
>> 
>> 
>> 
>> Javascript Async Test
>> 
>> 
>> function httpGetAsync(theUrl)
>> {
>>   var xmlHttp = new XMLHttpRequest();
>>   xmlHttp.onreadystatechange = function() {
>>   if (xmlHttp.readyState == 4 && 

Re: Not sure what to do.....can I run this by you guys?

this solution has to work flawlessly in production on all 3 desktop
platforms.

I'm giving a shot to modifying LibURL. I wish I knew why the limit is
in there to begin with, that would help to know if I am wasting my time or
not.

Realistically if it was as easy as just hacking that code, someone would
have done it already.

Its fun anywaysI have to solve this...even if I speed it up just a
little bit ..

Its not an emergency situation so its a fun problem to think about until
its solved.

some good ideas from you guys thanks everyone

On Fri, Mar 16, 2018 at 11:31 AM, Mike Bonner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yeah, thats what I was talking about, but I never tried it with safari i'm
> afraid. Sounds like something funky with safari, though i'm not sure why my
> method wouldn't work unless safari is smart enough now to recognize an
> inline link and NOT treat it as a new URL to cache.
>
> If this is only for your personal use, you can disable caching on safari as
> described here: https://www.technipages.com/apple-safari-completely-
> disable-cache
> If you have safari 11, check here instead to disable cache:
> https://stackoverflow.com/questions/46324675/how-do-
> i-disable-cache-in-safari-11-0
>
> If this is for an app being shipped though thats not a solution.  You said
> firefox works fine, so i'm guessing you don't have some type of caching
> proxy between you and the server.  Either way, from what I've been reading
> just now, rather than using meta tags, you're more likely to get the
> desired result if you set the headers directly.  One way to do this would
> be with an .htaccess file.
> https://stackoverflow.com/questions/11532636/how-to-
> prevent-http-file-caching-in-apache-httpd-mamp
>  You'd need to add .lc to the filesmatch so that they're not cached.
>
> Hopefully the correct module is installed. If it isn't, while I've never
> done it, I believe you can set the headers to return using lc in your
> server script (assuming you're using lc.) I know php can.  If you're using
> something other than apache of course, ignore the above.
>
> On Fri, Mar 16, 2018 at 8:53 AM, Rick Harrison via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Hi Mike,
> >
> > I am finding that Safari is not honoring
> > the meta tag to turn off caching.  I thought
> > I would give your method a try.  I’m not
> > sure I am doing it right though because
> > that isn’t working either.
> >
> > (Firefox does everything properly.)
> >
> > I was thinking from your description that
> > it would look something like:
> >
> > http://www.yourwebsite.com/coolpage.lc#48432 <
> http://www.yourwebsite.com/
> > coolpage.lc#48432>
> >
> > Is the above example of what you are discussing
> > correct?  If not could you please post an example?
> >
> > Thanks,
> >
> > Rick
> >
> > > On Mar 16, 2018, at 9:31 AM, Mike Bonner via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > Another way around the cache problem is to use the #2 trick at the end
> of
> > > the url.  Send each request with a pound and different number at the
> end
> > of
> > > the url and it'll be seen as a new request thus doing an end run around
> > the
> > > cache.  Since it designates an inline anchor position on the page, it
> > > should have zero affect on the way the url functions.  (unless things
> > have
> > > changed, the associated anchor doesn't need to exist on the page)
> > >
> > > Thanks for the neat trick Charles. :)
> > >
> > > On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > >> WowI'm impressedthats quite a hack Charles..I will study all
> > this
> > >> see how far I get.
> > >>
> > >> Thank you gentlemenyou are Rockstars!!
> > >>
> > >> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
> > >> use-livecode@lists.runrev.com> wrote:
> > >>
> > >>> Maybe not 100% reliable but 
> > >>>
> > >>> https://stackoverflow.com/questions/1341089/using-meta-
> > >>> tags-to-turn-off-caching-in-all-browsers
> > >>>
> > >>> Regards Lagi
> > >>>
> > >>> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
> > >>>  wrote:
> >  Hi Tom,
> > 
> >  If the site you are trying to contact has CORS enabled
> appropriately,
> > >>> then you can do something like this...
> > 
> >  With the LiveCode browser widget, you can call JavaScript functions
> > >> from
> > >>> LC script and have the JavaScript functions call LC handlers in
> return.
> > >>> JavaScript has the capability to perform asynchronous HTTP requests.
> > 
> >  You can create a HTML page that you automatically load up in the
> > >> browser
> > >>> widget that has a small JavaScript function which you can call from
> LC
> > >> with
> > >>> ‘do in widget’.   All this function needs to do is issue an
> > asynchronous
> > >>> HTTP call to the URL passed to it as a parameter and when 

Re: Not sure what to do.....can I run this by you guys?

Yeah, thats what I was talking about, but I never tried it with safari i'm
afraid. Sounds like something funky with safari, though i'm not sure why my
method wouldn't work unless safari is smart enough now to recognize an
inline link and NOT treat it as a new URL to cache.

If this is only for your personal use, you can disable caching on safari as
described here: https://www.technipages.com/apple-safari-completely-
disable-cache
If you have safari 11, check here instead to disable cache:
https://stackoverflow.com/questions/46324675/how-do-
i-disable-cache-in-safari-11-0

If this is for an app being shipped though thats not a solution.  You said
firefox works fine, so i'm guessing you don't have some type of caching
proxy between you and the server.  Either way, from what I've been reading
just now, rather than using meta tags, you're more likely to get the
desired result if you set the headers directly.  One way to do this would
be with an .htaccess file.
https://stackoverflow.com/questions/11532636/how-to-prevent-http-file-caching-in-apache-httpd-mamp
 You'd need to add .lc to the filesmatch so that they're not cached.

Hopefully the correct module is installed. If it isn't, while I've never
done it, I believe you can set the headers to return using lc in your
server script (assuming you're using lc.) I know php can.  If you're using
something other than apache of course, ignore the above.

On Fri, Mar 16, 2018 at 8:53 AM, Rick Harrison via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Mike,
>
> I am finding that Safari is not honoring
> the meta tag to turn off caching.  I thought
> I would give your method a try.  I’m not
> sure I am doing it right though because
> that isn’t working either.
>
> (Firefox does everything properly.)
>
> I was thinking from your description that
> it would look something like:
>
> http://www.yourwebsite.com/coolpage.lc#48432  coolpage.lc#48432>
>
> Is the above example of what you are discussing
> correct?  If not could you please post an example?
>
> Thanks,
>
> Rick
>
> > On Mar 16, 2018, at 9:31 AM, Mike Bonner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Another way around the cache problem is to use the #2 trick at the end of
> > the url.  Send each request with a pound and different number at the end
> of
> > the url and it'll be seen as a new request thus doing an end run around
> the
> > cache.  Since it designates an inline anchor position on the page, it
> > should have zero affect on the way the url functions.  (unless things
> have
> > changed, the associated anchor doesn't need to exist on the page)
> >
> > Thanks for the neat trick Charles. :)
> >
> > On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> WowI'm impressedthats quite a hack Charles..I will study all
> this
> >> see how far I get.
> >>
> >> Thank you gentlemenyou are Rockstars!!
> >>
> >> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> Maybe not 100% reliable but 
> >>>
> >>> https://stackoverflow.com/questions/1341089/using-meta-
> >>> tags-to-turn-off-caching-in-all-browsers
> >>>
> >>> Regards Lagi
> >>>
> >>> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
> >>>  wrote:
>  Hi Tom,
> 
>  If the site you are trying to contact has CORS enabled appropriately,
> >>> then you can do something like this...
> 
>  With the LiveCode browser widget, you can call JavaScript functions
> >> from
> >>> LC script and have the JavaScript functions call LC handlers in return.
> >>> JavaScript has the capability to perform asynchronous HTTP requests.
> 
>  You can create a HTML page that you automatically load up in the
> >> browser
> >>> widget that has a small JavaScript function which you can call from LC
> >> with
> >>> ‘do in widget’.   All this function needs to do is issue an
> asynchronous
> >>> HTTP call to the URL passed to it as a parameter and when it receives
> the
> >>> data, return it back to your LC script by calling a nominated LC
> handler
> >>> and passing the returned data as a parameter.
> 
>  The HTML page would look something like this:
> 
>  
>  
>  Javascript Async Test
>  
> 
>  function httpGetAsync(theUrl)
>  {
> var xmlHttp = new XMLHttpRequest();
> xmlHttp.onreadystatechange = function() {
> if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
> liveCode.httpRequestComplete(theUrl,
> >> xmlHttp.responseText);
> }
> xmlHttp.open("GET", theUrl, true); // true for asynchronous
> xmlHttp.send(null);
>  }
>  
>  
>  
>  
>  
> 
>  You can either load that from a file into the browser widget’s URL or
> >>> set its htmlText property accordingly...
> 
>  Then in 

Re: Not sure what to do.....can I run this by you guys?

Hi Mike,

I am finding that Safari is not honoring
the meta tag to turn off caching.  I thought
I would give your method a try.  I’m not
sure I am doing it right though because
that isn’t working either.

(Firefox does everything properly.)

I was thinking from your description that
it would look something like:

http://www.yourwebsite.com/coolpage.lc#48432 


Is the above example of what you are discussing
correct?  If not could you please post an example?

Thanks,

Rick 

> On Mar 16, 2018, at 9:31 AM, Mike Bonner via use-livecode 
>  wrote:
> 
> Another way around the cache problem is to use the #2 trick at the end of
> the url.  Send each request with a pound and different number at the end of
> the url and it'll be seen as a new request thus doing an end run around the
> cache.  Since it designates an inline anchor position on the page, it
> should have zero affect on the way the url functions.  (unless things have
> changed, the associated anchor doesn't need to exist on the page)
> 
> Thanks for the neat trick Charles. :)
> 
> On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> WowI'm impressedthats quite a hack Charles..I will study all this
>> see how far I get.
>> 
>> Thank you gentlemenyou are Rockstars!!
>> 
>> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Maybe not 100% reliable but 
>>> 
>>> https://stackoverflow.com/questions/1341089/using-meta-
>>> tags-to-turn-off-caching-in-all-browsers
>>> 
>>> Regards Lagi
>>> 
>>> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
>>>  wrote:
 Hi Tom,
 
 If the site you are trying to contact has CORS enabled appropriately,
>>> then you can do something like this...
 
 With the LiveCode browser widget, you can call JavaScript functions
>> from
>>> LC script and have the JavaScript functions call LC handlers in return.
>>> JavaScript has the capability to perform asynchronous HTTP requests.
 
 You can create a HTML page that you automatically load up in the
>> browser
>>> widget that has a small JavaScript function which you can call from LC
>> with
>>> ‘do in widget’.   All this function needs to do is issue an asynchronous
>>> HTTP call to the URL passed to it as a parameter and when it receives the
>>> data, return it back to your LC script by calling a nominated LC handler
>>> and passing the returned data as a parameter.
 
 The HTML page would look something like this:
 
 
 
 Javascript Async Test
 
 
 function httpGetAsync(theUrl)
 {
var xmlHttp = new XMLHttpRequest();
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
liveCode.httpRequestComplete(theUrl,
>> xmlHttp.responseText);
}
xmlHttp.open("GET", theUrl, true); // true for asynchronous
xmlHttp.send(null);
 }
 
 
 
 
 
 
 You can either load that from a file into the browser widget’s URL or
>>> set its htmlText property accordingly...
 
 Then in LC, make sure you register the httpRequestComplete handler so
>>> that the widget can call it:
 
 set the javascriptHandlers of widget “browser” to “httpRequestComplete”
 
 After that, add a httpRequestComplete handler to the card script to
>>> handle the returned data:
 
 on httpRequestComplete pUrl, pData
   — pUrl will be the URL requested
   — pData will be the data returned from the URL requested
 end httpRequestComplete
 
 Lastly, make your async requests
 
 do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”
 
 Since the JavaScript in the browser widget is issuing the requests and
>>> sending the data back to LC, it doesn’t need to display anything related
>> to
>>> it in the browser widget itself - it can be a blank canvas.
 
 Just be aware that the browser widget can cache URLs and there is no
>>> easy way (that I know of?) in LC to clear the browser’s cache... so if
>> you
>>> see very quick responses on a second or subsequent request to the same
>> URL,
>>> it is likely pulling it all from the browser’s cache.
 
 Cheers,
 
 Charles
 
>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
>> 
>> Great hints there Mike  thanks alot.  Luckily I'm desktop only
>>> right
>> now.
>> 
>> It shouldn't be too long before I sit down to make something that I
>> can
>> rely on and reuse in future projects.
>> 
>> Might turn out I will have to hire someone to help which is cool too.
>> 
>> It only has to be very simple..and does not need to match performance
>>> of
>> Tsnet.
>> 

Re: Not sure what to do.....can I run this by you guys?

Yes Mike that is a helpful trick.

On Fri, Mar 16, 2018 at 9:31 AM, Mike Bonner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Another way around the cache problem is to use the #2 trick at the end of
> the url.  Send each request with a pound and different number at the end of
> the url and it'll be seen as a new request thus doing an end run around the
> cache.  Since it designates an inline anchor position on the page, it
> should have zero affect on the way the url functions.  (unless things have
> changed, the associated anchor doesn't need to exist on the page)
>
> Thanks for the neat trick Charles. :)
>
> On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > WowI'm impressedthats quite a hack Charles..I will study all this
> > see how far I get.
> >
> > Thank you gentlemenyou are Rockstars!!
> >
> > On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > Maybe not 100% reliable but 
> > >
> > > https://stackoverflow.com/questions/1341089/using-meta-
> > > tags-to-turn-off-caching-in-all-browsers
> > >
> > > Regards Lagi
> > >
> > > On 16 March 2018 at 09:48, Charles Warwick via use-livecode
> > >  wrote:
> > > >  Hi Tom,
> > > >
> > > > If the site you are trying to contact has CORS enabled appropriately,
> > > then you can do something like this...
> > > >
> > > > With the LiveCode browser widget, you can call JavaScript functions
> > from
> > > LC script and have the JavaScript functions call LC handlers in return.
> > > JavaScript has the capability to perform asynchronous HTTP requests.
> > > >
> > > > You can create a HTML page that you automatically load up in the
> > browser
> > > widget that has a small JavaScript function which you can call from LC
> > with
> > > ‘do in widget’.   All this function needs to do is issue an
> asynchronous
> > > HTTP call to the URL passed to it as a parameter and when it receives
> the
> > > data, return it back to your LC script by calling a nominated LC
> handler
> > > and passing the returned data as a parameter.
> > > >
> > > > The HTML page would look something like this:
> > > >
> > > > 
> > > > 
> > > > Javascript Async Test
> > > > 
> > > >
> > > > function httpGetAsync(theUrl)
> > > > {
> > > > var xmlHttp = new XMLHttpRequest();
> > > > xmlHttp.onreadystatechange = function() {
> > > > if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
> > > > liveCode.httpRequestComplete(theUrl,
> > xmlHttp.responseText);
> > > > }
> > > > xmlHttp.open("GET", theUrl, true); // true for asynchronous
> > > > xmlHttp.send(null);
> > > > }
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > You can either load that from a file into the browser widget’s URL or
> > > set its htmlText property accordingly...
> > > >
> > > > Then in LC, make sure you register the httpRequestComplete handler so
> > > that the widget can call it:
> > > >
> > > > set the javascriptHandlers of widget “browser” to
> “httpRequestComplete”
> > > >
> > > > After that, add a httpRequestComplete handler to the card script to
> > > handle the returned data:
> > > >
> > > > on httpRequestComplete pUrl, pData
> > > >— pUrl will be the URL requested
> > > >— pData will be the data returned from the URL requested
> > > > end httpRequestComplete
> > > >
> > > > Lastly, make your async requests
> > > >
> > > > do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”
> > > >
> > > > Since the JavaScript in the browser widget is issuing the requests
> and
> > > sending the data back to LC, it doesn’t need to display anything
> related
> > to
> > > it in the browser widget itself - it can be a blank canvas.
> > > >
> > > > Just be aware that the browser widget can cache URLs and there is no
> > > easy way (that I know of?) in LC to clear the browser’s cache... so if
> > you
> > > see very quick responses on a second or subsequent request to the same
> > URL,
> > > it is likely pulling it all from the browser’s cache.
> > > >
> > > > Cheers,
> > > >
> > > > Charles
> > > >
> > > >>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > > >>>
> > > >>> Great hints there Mike  thanks alot.  Luckily I'm desktop only
> > > right
> > > >>> now.
> > > >>>
> > > >>> It shouldn't be too long before I sit down to make something that I
> > can
> > > >>> rely on and reuse in future projects.
> > > >>>
> > > >>> Might turn out I will have to hire someone to help which is cool
> too.
> > > >>>
> > > >>> It only has to be very simple..and does not need to match
> performance
> > > of
> > > >>> Tsnet.
> > > >>>
> > > >>> Anything more than 1 would be a great start. LOL.
> > > >>>
> > > >>> I will look into the libURL library and then try to guess which
> way I
> > > >>> should go my first attempt to hack this.
> > > >>>
> > 

Re: Not sure what to do.....can I run this by you guys?

Another way around the cache problem is to use the #2 trick at the end of
the url.  Send each request with a pound and different number at the end of
the url and it'll be seen as a new request thus doing an end run around the
cache.  Since it designates an inline anchor position on the page, it
should have zero affect on the way the url functions.  (unless things have
changed, the associated anchor doesn't need to exist on the page)

Thanks for the neat trick Charles. :)

On Fri, Mar 16, 2018 at 7:24 AM, Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> WowI'm impressedthats quite a hack Charles..I will study all this
> see how far I get.
>
> Thank you gentlemenyou are Rockstars!!
>
> On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Maybe not 100% reliable but 
> >
> > https://stackoverflow.com/questions/1341089/using-meta-
> > tags-to-turn-off-caching-in-all-browsers
> >
> > Regards Lagi
> >
> > On 16 March 2018 at 09:48, Charles Warwick via use-livecode
> >  wrote:
> > >  Hi Tom,
> > >
> > > If the site you are trying to contact has CORS enabled appropriately,
> > then you can do something like this...
> > >
> > > With the LiveCode browser widget, you can call JavaScript functions
> from
> > LC script and have the JavaScript functions call LC handlers in return.
> > JavaScript has the capability to perform asynchronous HTTP requests.
> > >
> > > You can create a HTML page that you automatically load up in the
> browser
> > widget that has a small JavaScript function which you can call from LC
> with
> > ‘do in widget’.   All this function needs to do is issue an asynchronous
> > HTTP call to the URL passed to it as a parameter and when it receives the
> > data, return it back to your LC script by calling a nominated LC handler
> > and passing the returned data as a parameter.
> > >
> > > The HTML page would look something like this:
> > >
> > > 
> > > 
> > > Javascript Async Test
> > > 
> > >
> > > function httpGetAsync(theUrl)
> > > {
> > > var xmlHttp = new XMLHttpRequest();
> > > xmlHttp.onreadystatechange = function() {
> > > if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
> > > liveCode.httpRequestComplete(theUrl,
> xmlHttp.responseText);
> > > }
> > > xmlHttp.open("GET", theUrl, true); // true for asynchronous
> > > xmlHttp.send(null);
> > > }
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > You can either load that from a file into the browser widget’s URL or
> > set its htmlText property accordingly...
> > >
> > > Then in LC, make sure you register the httpRequestComplete handler so
> > that the widget can call it:
> > >
> > > set the javascriptHandlers of widget “browser” to “httpRequestComplete”
> > >
> > > After that, add a httpRequestComplete handler to the card script to
> > handle the returned data:
> > >
> > > on httpRequestComplete pUrl, pData
> > >— pUrl will be the URL requested
> > >— pData will be the data returned from the URL requested
> > > end httpRequestComplete
> > >
> > > Lastly, make your async requests
> > >
> > > do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”
> > >
> > > Since the JavaScript in the browser widget is issuing the requests and
> > sending the data back to LC, it doesn’t need to display anything related
> to
> > it in the browser widget itself - it can be a blank canvas.
> > >
> > > Just be aware that the browser widget can cache URLs and there is no
> > easy way (that I know of?) in LC to clear the browser’s cache... so if
> you
> > see very quick responses on a second or subsequent request to the same
> URL,
> > it is likely pulling it all from the browser’s cache.
> > >
> > > Cheers,
> > >
> > > Charles
> > >
> > >>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >>>
> > >>> Great hints there Mike  thanks alot.  Luckily I'm desktop only
> > right
> > >>> now.
> > >>>
> > >>> It shouldn't be too long before I sit down to make something that I
> can
> > >>> rely on and reuse in future projects.
> > >>>
> > >>> Might turn out I will have to hire someone to help which is cool too.
> > >>>
> > >>> It only has to be very simple..and does not need to match performance
> > of
> > >>> Tsnet.
> > >>>
> > >>> Anything more than 1 would be a great start. LOL.
> > >>>
> > >>> I will look into the libURL library and then try to guess which way I
> > >>> should go my first attempt to hack this.
> > >>>
> > >>> I'll keep you guys posted on the progress..I think I need a name for
> > this
> > >>> little project.
> > >>>
> > >>> Thanks you
> > >>>
> > >>> Tom
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > 

Re: Not sure what to do.....can I run this by you guys?

WowI'm impressedthats quite a hack Charles..I will study all this
see how far I get.

Thank you gentlemenyou are Rockstars!!

On Fri, Mar 16, 2018 at 7:13 AM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Maybe not 100% reliable but 
>
> https://stackoverflow.com/questions/1341089/using-meta-
> tags-to-turn-off-caching-in-all-browsers
>
> Regards Lagi
>
> On 16 March 2018 at 09:48, Charles Warwick via use-livecode
>  wrote:
> >  Hi Tom,
> >
> > If the site you are trying to contact has CORS enabled appropriately,
> then you can do something like this...
> >
> > With the LiveCode browser widget, you can call JavaScript functions from
> LC script and have the JavaScript functions call LC handlers in return.
> JavaScript has the capability to perform asynchronous HTTP requests.
> >
> > You can create a HTML page that you automatically load up in the browser
> widget that has a small JavaScript function which you can call from LC with
> ‘do in widget’.   All this function needs to do is issue an asynchronous
> HTTP call to the URL passed to it as a parameter and when it receives the
> data, return it back to your LC script by calling a nominated LC handler
> and passing the returned data as a parameter.
> >
> > The HTML page would look something like this:
> >
> > 
> > 
> > Javascript Async Test
> > 
> >
> > function httpGetAsync(theUrl)
> > {
> > var xmlHttp = new XMLHttpRequest();
> > xmlHttp.onreadystatechange = function() {
> > if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
> > liveCode.httpRequestComplete(theUrl, xmlHttp.responseText);
> > }
> > xmlHttp.open("GET", theUrl, true); // true for asynchronous
> > xmlHttp.send(null);
> > }
> > 
> > 
> > 
> > 
> > 
> >
> > You can either load that from a file into the browser widget’s URL or
> set its htmlText property accordingly...
> >
> > Then in LC, make sure you register the httpRequestComplete handler so
> that the widget can call it:
> >
> > set the javascriptHandlers of widget “browser” to “httpRequestComplete”
> >
> > After that, add a httpRequestComplete handler to the card script to
> handle the returned data:
> >
> > on httpRequestComplete pUrl, pData
> >— pUrl will be the URL requested
> >— pData will be the data returned from the URL requested
> > end httpRequestComplete
> >
> > Lastly, make your async requests
> >
> > do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”
> >
> > Since the JavaScript in the browser widget is issuing the requests and
> sending the data back to LC, it doesn’t need to display anything related to
> it in the browser widget itself - it can be a blank canvas.
> >
> > Just be aware that the browser widget can cache URLs and there is no
> easy way (that I know of?) in LC to clear the browser’s cache... so if you
> see very quick responses on a second or subsequent request to the same URL,
> it is likely pulling it all from the browser’s cache.
> >
> > Cheers,
> >
> > Charles
> >
> >>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> Great hints there Mike  thanks alot.  Luckily I'm desktop only
> right
> >>> now.
> >>>
> >>> It shouldn't be too long before I sit down to make something that I can
> >>> rely on and reuse in future projects.
> >>>
> >>> Might turn out I will have to hire someone to help which is cool too.
> >>>
> >>> It only has to be very simple..and does not need to match performance
> of
> >>> Tsnet.
> >>>
> >>> Anything more than 1 would be a great start. LOL.
> >>>
> >>> I will look into the libURL library and then try to guess which way I
> >>> should go my first attempt to hack this.
> >>>
> >>> I'll keep you guys posted on the progress..I think I need a name for
> this
> >>> little project.
> >>>
> >>> Thanks you
> >>>
> >>> Tom
> > ___
> > use-livecode mailing list
> > use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Not sure what to do.....can I run this by you guys?

Maybe not 100% reliable but 

https://stackoverflow.com/questions/1341089/using-meta-tags-to-turn-off-caching-in-all-browsers

Regards Lagi

On 16 March 2018 at 09:48, Charles Warwick via use-livecode
 wrote:
>  Hi Tom,
>
> If the site you are trying to contact has CORS enabled appropriately, then 
> you can do something like this...
>
> With the LiveCode browser widget, you can call JavaScript functions from LC 
> script and have the JavaScript functions call LC handlers in return.  
> JavaScript has the capability to perform asynchronous HTTP requests.
>
> You can create a HTML page that you automatically load up in the browser 
> widget that has a small JavaScript function which you can call from LC with 
> ‘do in widget’.   All this function needs to do is issue an asynchronous HTTP 
> call to the URL passed to it as a parameter and when it receives the data, 
> return it back to your LC script by calling a nominated LC handler and 
> passing the returned data as a parameter.
>
> The HTML page would look something like this:
>
> 
> 
> Javascript Async Test
> 
>
> function httpGetAsync(theUrl)
> {
> var xmlHttp = new XMLHttpRequest();
> xmlHttp.onreadystatechange = function() {
> if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
> liveCode.httpRequestComplete(theUrl, xmlHttp.responseText);
> }
> xmlHttp.open("GET", theUrl, true); // true for asynchronous
> xmlHttp.send(null);
> }
> 
> 
> 
> 
> 
>
> You can either load that from a file into the browser widget’s URL or set its 
> htmlText property accordingly...
>
> Then in LC, make sure you register the httpRequestComplete handler so that 
> the widget can call it:
>
> set the javascriptHandlers of widget “browser” to “httpRequestComplete”
>
> After that, add a httpRequestComplete handler to the card script to handle 
> the returned data:
>
> on httpRequestComplete pUrl, pData
>— pUrl will be the URL requested
>— pData will be the data returned from the URL requested
> end httpRequestComplete
>
> Lastly, make your async requests
>
> do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”
>
> Since the JavaScript in the browser widget is issuing the requests and 
> sending the data back to LC, it doesn’t need to display anything related to 
> it in the browser widget itself - it can be a blank canvas.
>
> Just be aware that the browser widget can cache URLs and there is no easy way 
> (that I know of?) in LC to clear the browser’s cache... so if you see very 
> quick responses on a second or subsequent request to the same URL, it is 
> likely pulling it all from the browser’s cache.
>
> Cheers,
>
> Charles
>
>>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode 
>>>  wrote:
>>>
>>> Great hints there Mike  thanks alot.  Luckily I'm desktop only right
>>> now.
>>>
>>> It shouldn't be too long before I sit down to make something that I can
>>> rely on and reuse in future projects.
>>>
>>> Might turn out I will have to hire someone to help which is cool too.
>>>
>>> It only has to be very simple..and does not need to match performance of
>>> Tsnet.
>>>
>>> Anything more than 1 would be a great start. LOL.
>>>
>>> I will look into the libURL library and then try to guess which way I
>>> should go my first attempt to hack this.
>>>
>>> I'll keep you guys posted on the progress..I think I need a name for this
>>> little project.
>>>
>>> Thanks you
>>>
>>> Tom
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Not sure what to do.....can I run this by you guys?

 Hi Tom,

If the site you are trying to contact has CORS enabled appropriately, then you 
can do something like this...

With the LiveCode browser widget, you can call JavaScript functions from LC 
script and have the JavaScript functions call LC handlers in return.  
JavaScript has the capability to perform asynchronous HTTP requests.

You can create a HTML page that you automatically load up in the browser widget 
that has a small JavaScript function which you can call from LC with ‘do in 
widget’.   All this function needs to do is issue an asynchronous HTTP call to 
the URL passed to it as a parameter and when it receives the data, return it 
back to your LC script by calling a nominated LC handler and passing the 
returned data as a parameter.

The HTML page would look something like this:



Javascript Async Test


function httpGetAsync(theUrl)
{
var xmlHttp = new XMLHttpRequest();
xmlHttp.onreadystatechange = function() { 
if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
liveCode.httpRequestComplete(theUrl, xmlHttp.responseText);
}
xmlHttp.open("GET", theUrl, true); // true for asynchronous 
xmlHttp.send(null);
}






You can either load that from a file into the browser widget’s URL or set its 
htmlText property accordingly...

Then in LC, make sure you register the httpRequestComplete handler so that the 
widget can call it:

set the javascriptHandlers of widget “browser” to “httpRequestComplete”

After that, add a httpRequestComplete handler to the card script to handle the 
returned data:

on httpRequestComplete pUrl, pData
   — pUrl will be the URL requested
   — pData will be the data returned from the URL requested
end httpRequestComplete

Lastly, make your async requests

do (“httpGetAsync(‘http://www.livecode.com’);” in widget “browser”

Since the JavaScript in the browser widget is issuing the requests and sending 
the data back to LC, it doesn’t need to display anything related to it in the 
browser widget itself - it can be a blank canvas.

Just be aware that the browser widget can cache URLs and there is no easy way 
(that I know of?) in LC to clear the browser’s cache... so if you see very 
quick responses on a second or subsequent request to the same URL, it is likely 
pulling it all from the browser’s cache.

Cheers,

Charles

>> On 16 Mar 2018, at 1:35 pm, Tom Glod via use-livecode 
>>  wrote:
>> 
>> Great hints there Mike  thanks alot.  Luckily I'm desktop only right
>> now.
>> 
>> It shouldn't be too long before I sit down to make something that I can
>> rely on and reuse in future projects.
>> 
>> Might turn out I will have to hire someone to help which is cool too.
>> 
>> It only has to be very simple..and does not need to match performance of
>> Tsnet.
>> 
>> Anything more than 1 would be a great start. LOL.
>> 
>> I will look into the libURL library and then try to guess which way I
>> should go my first attempt to hack this.
>> 
>> I'll keep you guys posted on the progress..I think I need a name for this
>> little project.
>> 
>> Thanks you
>> 
>> Tom
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Not sure what to do.....can I run this by you guys?


Tom Glod wrote:

>  I'll keep you guys posted on the progress..I think I need a name for
> this little project.

"There are only two hard things in Computer Science: cache invalidation 
and naming things."

- Phil Karlton


--
 Richard Gaskin
 Fourth World Systems

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Not sure what to do.....can I run this by you guys?

Great hints there Mike  thanks alot.  Luckily I'm desktop only right
now.

It shouldn't be too long before I sit down to make something that I can
rely on and reuse in future projects.

Might turn out I will have to hire someone to help which is cool too.

It only has to be very simple..and does not need to match performance of
Tsnet.

Anything more than 1 would be a great start. LOL.

I will look into the libURL library and then try to guess which way I
should go my first attempt to hack this.

I'll keep you guys posted on the progress..I think I need a name for this
little project.

Thanks you

Tom


On Thu, Mar 15, 2018 at 10:35 PM, Mike Bonner via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I've used load for this in the past.  The ability to specify a callback
> message makes it work well.  In my case I was experimenting with offloading
> a large job to a webserver for processing.  To help with organizing the
> data being returned, I tacked a # and an incrementing number to the end of
> each url.  Made it easy to re-assemble things into the proper order.  (Be
> aware though, things behave differently between desktop and mobile so you
> have to take platform into account)
>
> On Thu, Mar 15, 2018 at 8:26 PM, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > i need to be able to send more than one http request to my cloud service
> > domain at one timeit is not a limitation I am willing to live with
> > and I don't want to package requests together and have to wait for
> all
> > of them to be processed before something comes back.
> >
> > Its not a limitation that should exist in any modern software. and it
> > won't in mine.. so I have to try different ways to try to get around
> > this somehow and still be GPL3
> >
> > CheersI'm going to try the read from process ideaand see if i can
> > read the returned requests faster that way.
> >
> > Thank you.
> >
> >
> >
> >
> >
> >
> > On Thu, Mar 15, 2018 at 10:14 PM, Richard Gaskin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > Tom Glod wrote:
> > > > Hi guys, I've brought this up before.and the time to solve is
> > > > coming sooner than I expected.
> > > >
> > > > 1. My project must be open source
> > > > 2. I must communicate with cloud service not one request at a time.
> > > > 3. TsNet is not open source and I love that LC has a feature that
> > > > can bring them important revenue.
> > > >
> > > > But I have to create a workaround ... so its hackathon time
> > > >
> > > > My first idea is to do this :
> > > >
> > > >- Create process in Go using Go Routines to give me concurrent
> http
> > > >requests
> > > >- send all my requests to that process via a non-blocking socket
> > > >- read from the socket in non-blocking way to receive the data
> > > >  returned
> > > >for the requests until all requests have completed or timed out.
> > >
> > > While it is unfortunate that LC is among the few open source languages
> > > that doesn't have CURL support, in your case I wonder if it's truly
> > > necessary.
> > >
> > > The engine's socket support is generally pretty good, and libURL can be
> > > modified.  What exactly do you need to do?
> > >
> > > --
> > >  Richard Gaskin
> > >  Fourth World Systems
> > >  Software Design and Development for the Desktop, Mobile, and the Web
> > >  
> > >  ambassa...@fourthworld.comhttp://www.FourthWorld.com
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Not sure what to do.....can I run this by you guys?

I've used load for this in the past.  The ability to specify a callback
message makes it work well.  In my case I was experimenting with offloading
a large job to a webserver for processing.  To help with organizing the
data being returned, I tacked a # and an incrementing number to the end of
each url.  Made it easy to re-assemble things into the proper order.  (Be
aware though, things behave differently between desktop and mobile so you
have to take platform into account)

On Thu, Mar 15, 2018 at 8:26 PM, Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> i need to be able to send more than one http request to my cloud service
> domain at one timeit is not a limitation I am willing to live with
> and I don't want to package requests together and have to wait for all
> of them to be processed before something comes back.
>
> Its not a limitation that should exist in any modern software. and it
> won't in mine.. so I have to try different ways to try to get around
> this somehow and still be GPL3
>
> CheersI'm going to try the read from process ideaand see if i can
> read the returned requests faster that way.
>
> Thank you.
>
>
>
>
>
>
> On Thu, Mar 15, 2018 at 10:14 PM, Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Tom Glod wrote:
> > > Hi guys, I've brought this up before.and the time to solve is
> > > coming sooner than I expected.
> > >
> > > 1. My project must be open source
> > > 2. I must communicate with cloud service not one request at a time.
> > > 3. TsNet is not open source and I love that LC has a feature that
> > > can bring them important revenue.
> > >
> > > But I have to create a workaround ... so its hackathon time
> > >
> > > My first idea is to do this :
> > >
> > >- Create process in Go using Go Routines to give me concurrent http
> > >requests
> > >- send all my requests to that process via a non-blocking socket
> > >- read from the socket in non-blocking way to receive the data
> > >  returned
> > >for the requests until all requests have completed or timed out.
> >
> > While it is unfortunate that LC is among the few open source languages
> > that doesn't have CURL support, in your case I wonder if it's truly
> > necessary.
> >
> > The engine's socket support is generally pretty good, and libURL can be
> > modified.  What exactly do you need to do?
> >
> > --
> >  Richard Gaskin
> >  Fourth World Systems
> >  Software Design and Development for the Desktop, Mobile, and the Web
> >  
> >  ambassa...@fourthworld.comhttp://www.FourthWorld.com
> >
> > ___
> > use-livecode mailing list
> > use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Not sure what to do.....can I run this by you guys?

i need to be able to send more than one http request to my cloud service
domain at one timeit is not a limitation I am willing to live with
and I don't want to package requests together and have to wait for all
of them to be processed before something comes back.

Its not a limitation that should exist in any modern software. and it
won't in mine.. so I have to try different ways to try to get around
this somehow and still be GPL3

CheersI'm going to try the read from process ideaand see if i can
read the returned requests faster that way.

Thank you.






On Thu, Mar 15, 2018 at 10:14 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Tom Glod wrote:
> > Hi guys, I've brought this up before.and the time to solve is
> > coming sooner than I expected.
> >
> > 1. My project must be open source
> > 2. I must communicate with cloud service not one request at a time.
> > 3. TsNet is not open source and I love that LC has a feature that
> > can bring them important revenue.
> >
> > But I have to create a workaround ... so its hackathon time
> >
> > My first idea is to do this :
> >
> >- Create process in Go using Go Routines to give me concurrent http
> >requests
> >- send all my requests to that process via a non-blocking socket
> >- read from the socket in non-blocking way to receive the data
> >  returned
> >for the requests until all requests have completed or timed out.
>
> While it is unfortunate that LC is among the few open source languages
> that doesn't have CURL support, in your case I wonder if it's truly
> necessary.
>
> The engine's socket support is generally pretty good, and libURL can be
> modified.  What exactly do you need to do?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Not sure what to do.....can I run this by you guys?


Tom Glod wrote:
> Hi guys, I've brought this up before.and the time to solve is
> coming sooner than I expected.
>
> 1. My project must be open source
> 2. I must communicate with cloud service not one request at a time.
> 3. TsNet is not open source and I love that LC has a feature that
> can bring them important revenue.
>
> But I have to create a workaround ... so its hackathon time
>
> My first idea is to do this :
>
>- Create process in Go using Go Routines to give me concurrent http
>requests
>- send all my requests to that process via a non-blocking socket
>- read from the socket in non-blocking way to receive the data
>  returned
>for the requests until all requests have completed or timed out.

While it is unfortunate that LC is among the few open source languages 
that doesn't have CURL support, in your case I wonder if it's truly 
necessary.


The engine's socket support is generally pretty good, and libURL can be 
modified.  What exactly do you need to do?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Not sure what to do.....can I run this by you guys?

Hi guys, I've brought this up before.and the time to solve is coming
sooner than I expected.

1. My project must be open source
2. I must communicate with cloud service not one request at a time.
3. TsNet is not open source and I love that LC has a feature that can bring
them important revenue.

But I have to create a workaround ... so its hackathon time

My first idea is to do this :

   - Create process in Go using Go Routines to give me concurrent http
   requests
   - send all my requests to that process via a non-blocking socket
   - read from the socket in non-blocking way to receive the data returned
   for the requests until all requests have completed or timed out.


thats the theory

i hope it works.

thanks you guys for any thouights
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode