All the RIA stuff aside....it sounds like you re-invented the wheel with your app....sounds an awful lot like the reems of day trader apps out there....does your do something special?

Bryan Stevenson B.Comm.
VP & Director of E-Commerce Development
Electric Edge Systems Group Inc.
t. 250.920.8830
e. [EMAIL PROTECTED]

---------------------------------------------------------
Macromedia Associate Partner
www.macromedia.com
---------------------------------------------------------
Vancouver Island ColdFusion Users Group
Founder & Director
www.cfug-vancouverisland.com
  ----- Original Message -----
  From: Dick Applebaum
  To: CF-Talk
  Sent: Tuesday, March 30, 2004 9:05 AM
  Subject: SOT: RIA thoughts (longish)

  RIAs

  It is likely that each of can see the need for an RIA for certain apps
  and/or parts of other apps,

  I suspect that there very few cases where we would use an RIA for
  flaming logos or barndoor-wipe page transitions -- a lot of overhead,
  adds little to the user experience, and gets tedious real fast.

  There are a few specialty AV apps I would like to do using mp3s, photos
  and movies (manage my own collections of these).

  But, I expect the majority the time i would use RIA components for data
  grids, drill-downs, data maintenance and menus (popup, trees, etc).

  I have one special app that appears to be an ideal candidate for an
  RIA.  It is a grid of typically 20 columns by 30 rows and represents a
  stock portfolio.  about 80% of the data is static (days, held, number
  of shares, ticker symbol, purchase price, etc).  The other data
  (current price, profit/loss, potential ROI, buy/sell thresholds, etc.)
  is very dynamic during market hours,

  The dynamic data comes from a streaming service and is quasi real-time
  (there is no artificial delay, the service provides data as fast as it
  gets it).  When the streaming data is received at the host, the host
  programs determines what has changed (and by how much), if any
  thresholds are reached (or being approached), etc.  Then, only these
  changes are sent to the client, where the grid cells are updated.  When
  the changes are displayed, the individual cells may change color to
  indicate amount of profit/loss, that the price is approaching the
  target buy/sell price, etc. With all the lights flashing on and off it
  is kind of like a big video game-- portfolio pachinko!  But it is very
  useful -- the colors draw your attention to what needs your attention
  or assure you with a glance that a given stock position is/is not
  performing as expected.

  As I type this MACR is up $.36  at $20.10 --- oops up $.33 at $20.07.  
  It is towards the high of the $17.50 (Buy) and $21,50 (Sell) thresholds
  -- no action required.

  I have written 21/2 versions of this program:

  1)  HTML only refresh entire page (dense update)
  2)  Flash RIA client with datagrid component (sparse update) - slower
  than above, but no annoying page refresh
  2 1/2)  Hidden frame _javascript_ client (semi-sparse* update) - faster
  than either of the above and no annoying page refresh.

  * I augmented the code in step 1 to generate a structure with only the
  changes.  this and the entire (updated) html page are sent to a hidden
  frame. The _javascript_ at the client parses the data structure and
  updates the individual cells of the grid in the visible frame (no
  refresh).  It's a hack, but it works pretty well.

  I am currently writing version 3 using some client-side web service
  _javascript_ routines by Rob Rohan -- looks very promising.

  But, that's a story for later.  My point here, is that I tried a Flash
  RIA and it didn't perform well.  The stock streamer service provides a
  Java applet, but it is inflexible, doesn't contain required data, and
  gets behind real-time by 5-7 minutes during peak market hours.

  Why didn't  the Flash RIA perform -- the best we could come up with is
  it's the nature of the beast -- Flash just isn't a good fit for this
  app.

  OK, fair enough.  But I did gain some experience with Flash and RIAs.

  I noticed something that I had never really thought about.  there is
  quite a price to pay for RIAs (over and above the Flash plugin and the
  swf download time).  To test my program I had several open windows in
  multiple browsers all displaying versions of my RIA app.  The overhead
  was quite noticeable. Each browser window had a swf with my RIA
  competing for resources on the client.

  "Well, that's unrealistic!": you might say.  But, is it really?  As
  RIAs gain popularity throughout the web won't there be a high
  probability of running multiple RIAs, (from the same or different
  sources) concurrently, on a given desktop? Whew, that was a mouth full!

  Of course, hardware technology advances will tend to mitigate the issue.

  All this recent Flex chatter has made me rethink RIAs in a broader
  sense.

  To illustrate: If you go to the flex product page:

      
  http://www.macromedia.com/software/flex/?promoid=home_prod_flex_111703#

  and click the link to the Flex code explorer.

    Aside:  I am an old cuss, but it bothers me (more than a little) that
  RIA links don't look like regular (HTML) links and the enter key
  doesn't submit a form and hints sometimes  popup too fast...

  Anyway, the Flash Code Explorer pops up in another window.

  On my DSL link (and it's a good one), the popup  takes about 7 seconds
  to load and about 3 seconds to render -- par for the course, I guess,

  But, this showcase app feels "heavy" or "sticky".

  The tree menu is one of the slowest I have seen... with noticeable
  pauses when you open the top folder and push down the others.

  Then, with the "sample" tab selected, click through the various tour
  items.  With each change a little initializing box pops for a second or
  2 and then the example is displayed.  That seems awfully slow.

  Given this uneasiness with what I experienced, I did some rough timings
  to see if I could quantify the cost (at the client) of an RIA

  Here are my findings:

     Mozilla 1.6 Mac OS X 10.3.3                 CPU %     Threads      
  Real Mem    Virt Mem
     -----------------------------------       --------    -------     
  ---------   ----------
     No windows open.........................       1%         11         
    46M        425M

     Mozilla Home page HTML (1)..............       1%         12         
    53M        432M

     Flex Product page (2)...................   12-17%         19         
    60M        443M

     Flex Samples (Code) Explorer Popup (3)..   25-29%         20         
    73M        462M

     Flex Explorer Popup (4)                    11-15%         13         
    70M        449M

     (1) Simple animation (gifs, etc)
     (2)
  http://www.macromedia.com/software/flex/?promoid=home_prod_flex_111703#
     (3) takes 7 seconds to load and about 3 seconds to render)
     (3) these measurements have the flex product page and the popup open
  concurrently
     (4) Popup window is the only window open

  Not a scientific timing for sure... just a rough "eyeball" of some
  slices in time -- with a normal (for me) mix of other stuff going on.

  But, I think the exercise illustrates at least 3 points.

  1) RIAs have a cost -- they continuously consume CPU cycles whether
  they are being used or not.

  2) Multiple RIAs on the same desktop are highly probable and they
  compete for valuable client resources.

  3) A RIA that performs poorly loses much of its advantage (or, its
  reason for existence).

  I am a strong advocate of "doing it well" -- as well as you can.  I
  also believe that "anything worth doing, is worth doing, badly (if
  that's the only choice)"

  But with RIAs the latter may be inappropriate --a UI is a very personal
  thing, like your "favorite" chair ... it's comfortable... or it's not!.

  If a RIA is too slow (or too fast) it becomes "uncomfortable" and you
  feel bothered, uneasy, distracted... ready to quit!

  Then there is the matter of drill-down and data maintenance --

  So, instead of downloading the next/prev n records in a drill-down, in
  an RIA we download all the records (or a bigger subset) and let the
  user browse thru them at the client --
  we substitute one large data download for several smaller (and maybe
  fewer overall records).  Bandwidth isn't free -- neither are the server
  cycles and memory to retrieve format (HTML, XML) and serialized the
  data. Nor are these items free on the client -- especially not on the
  client.  If the RIA app is well designed and the optimal amount of data
  is pre-downloaded, maybe we get a wssh (versus the next/prev n records)
  -- maybe not.

  Did you ever browser-refresh a RIA page?

  Then I've heard:  "you have all the data you need on the client... you
  can browse through the data and update any records without any
  interaction with the server... once all the updates are complete, you
  just send them to the server..."

  Gee, How do you program that at the server?  What if multiple users
  concurrently update the same record? What if the client machine
  reboots, the browser crashes, or the user does a browser-refresh
  page...

    "Are you saying that the changes, I entered for the last 3 hours are
  gone...GONE?

  Yeah, ain't that rich?

  I know that this is a SOT for this forum, but it seems that we, as CF
  developers are going be dealing with RIAs in the future if not
  presently doing so

  I am not so sure that RIAs are worth all the hype, nor that they can
  deliver all they being promised to do.

  Thoughts

  Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to