I'm unsure I'm adding anything to this thread but forgive me, I'm
going to add my 2 cents worth, you can give me change if you choose ;).

My (not so humble) opinion is that work should be done where work
should be done. If this seems cryptic it's because there are many
places now to do work, that perhaps didn't exist in the past. For
instance, if you are doing zipcode format validating on the server, I
think perhaps you may not understand the load being carried by the
network and the server. 

In todays world of 2.4ghz, dual core, 2 gig laptops (the Dell I'm
typing this on, for instance), I believe it's pretty foolish to send
all of that work to the server where a thread will probably be created
and the result sent back. Why would you willfully create a thread for
such a simple mechanism (this may be a poor example but I see it often
enough from developers that don't know about the 7 (8) fallacies of
network programming) and "grew up" in the days of mainframes. I think
much of the debate about doing the "work" on the server is a vestigial
relic of the mainframe days. There are still an abundance of
developers that developed in the days when dumb terminals were the
common access to computing. 

Yes, Flex doesn't support true multi-threading and there are times
when I wish it did but the underlying Flash player has much exposed in
ways to dish off work (asynchronous tokens, etc., as you've mentioned).

The Flash player is written in Java (big shock there) and I know it's
already doing some substantial threading there. So my recommendation
would be to do as much work in the UI as you can and don't choke the
network and the server with unnecessary work.

After all, you are correct... that's why they're called RIA's.

--- In [email protected], "simonjpalmer" <[EMAIL PROTECTED]>
wrote:
>
> Funnily enough part of the reason I chose Flash was to offload a whack
> of work from the server on to the server-spec processors that every
> client machine now possesses (I'm currently using my dual processor
> 2GHz 4GbRAM laptop to type text into a web form!).  Compared to the
> old page based days of html web apps I get 100 times the performance
> and scalability on my server just by handing data to the client and
> letting it do a lot of what was traditionally server processing.  This
> is why I love Flash and I thought that was the point of a RIA.  That
> and the fact that our RIA apps feel like the desktop rather than the
web.
> 
> So while I agree that there should be an appropriate transaction size
> and handshake with the server I can also see a very good argument to
> say that the client should be more powerful.  Imagine if the player
> was multi-threaded... Why not use the processing power on the client
> to lighten the server load?  What's so special about the server that
> all the processing has to happen there?  It could then be purely a
> persistence tier with almost no business logic.  In some apps that
> would be highly desirable and in all cases would lead to more scalable
> servers.
> 
> Agree with the onions, never been close enough to an ogre to
> understand them completely, but I'm sure they are complex people too.
>  Conventional wisdom is certainly with you on the apps.
> 
> --- In [email protected], "barry.beattie" <barry.beattie@>
> wrote:
> >
> > 
> > > People have been begging for some kind of threading for  a long
time,
> > > but the Flash Player team seems pretty adamant that this won't
happen
> > > any time soon.
> > 
> > and, IMHO, fair enough too. The SWF is just the UI, it's not the whole
> > application**. There's async calls to the server and Java (and ow
> > CF)have threading as well. Just how much of the layers of an
> > application do people want the UI to do?
> > 
> > And it's quite possible that it won't just be the CF/PHP/Java code
> > that does the heavy lifting either (well, maybe not in this case...) -
> > it could very well be the database doing hundreds of lines of SQL
> > munging to get data to run some charts (eg: it doesn't make sence to
> > pull raw data into the SWF - then  do a ton of processing on a single
> > thread - just to run some charts).
> > 
> > Onions - they have layers. Ogres - they have layers. Applications -
> > they have layers too.
> > 
> > 
> > ** OK, so there are some grey areas where applications are ALL UI and
> > very little else. Still..
> >
>


Reply via email to