non-blocking http ... will tsnet end up in community?

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com