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.. > > >

