andrew at midwestcoastmedia.com wrote:
>> DDoS tools aside <g>, what APIs need more than one call at a time?
>>
>
> I can think of a use in my (relatively) simple Indiana On Tap mobile
> app. Currently I fetch some mySQL data and download some images from a
> HostM account through their SSL API. The data is a couple of arrays
> with a 30-300 entries each and the images are between 5KB-200KB.
> Sometimes these fire off super fast back-to-back-to-back finishing in
> 3 or 4 seconds, but other times there is a network lag (I've scripted
> some tests and determined it isn't the app or the server process) and
> the entire process takes up 25 seconds.
>
> Just recently while testing some REST stuff I discovered how to do the
> async tsNet calls (I second whomever suggested crowd funding Charles
> to write some tutorial stacks!). I think by calling these commands
> async will allow me to speed up the app initialization process: no
> waiting for server reply between each request so I can move onto the
> 1st non-splash card of the app.
>
> The speed increase and ability to make multiple concurrent
> non-blocking calls is also the key to allowing "Enable Background
> Execution" of this app. This unexpected bonus benefit is YUGE as that
> has been a complaint about the app.
Good example there, Andrew. Thanks for that.
I had a loosely-related need that isn't so much germain to this
discussion as just another story of how LC's flexibility can impress
people in the enterprise world where all they know is Java:
One of the client-server systems I've delivered includes a media
management library, where users can upload, modify, and select media
files from a collection of ~3,000 JPEG and MP4 files.
To provide the UI for that I wanted the list view to include thumbnails,
but of course early on I realized I didn't want 3,000 separate HTTP
requests to populate it.
After playing around with a few different combinations of JPEG quality
and resizing, I finally arrived at a solution that fit all those
thumbnails into a single compressed LSON file.
Between the image compression already in the JPEG data and the
efficiency of Gzip for the array key names and metadata, the entire
thumbnail archive takes up a mere 1.1 MB.
So when our users open the media library, a single request to the server
for a one-meg file populates a richly-visual DataGrid with thousands of
items, all in just a couple seconds. From there they can filter and
select flexibly, easily, and rapidly, since the entire archive is now
local in RAM.
Experimentation, deployment, and testing for both client and the
server-side stuff to maintain the thumbnails took less than a day.
Meanwhile, another team working for the same company was making a
similar subsystem for another product, but in Java. Somehow putting all
the thumbnails into a single array didn't occur to them, instead taking
the more common route of getting each one in a separate HTTP request,
and then having to use paging to limit the number of items that can be
seen on screen at any given time.
At the end of the day, they spent a heckuva lot more on their UI than I
did on mine, and their users complain that it's slow and limited.
I've tried suggesting LC to that team, but you know how it goes: "But
Java is the standard." ;)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://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
