Hi Vishal, I work in a real-time two-way communications domain, so I'm off at the edge here. But I find there are a small constellation of functions that just don't work now with browser-based applications without either employing crazy architectures or shoveling massive traffic across the network. Accessing network sockets, hooking multiple audio cards, audio mixing, disk access, complex network routing and peer networking are (rightly) frowned upon by browsers as security risks. The new Flash/Flex/Air and Silverlight client capabilities take me somewhat in the right direction (you can get to the local drives) but I still couldn't build our communications clients in them, not even in the Flash/Flex/Air/Silverlight of the dreamy-look future roadmap. Which is sad, because I want to.
If you are not working in a real-time domain though, these limitations may not apply to you. You may be able to deliver a higher level of fit and finish in an installed client, and it may allow your developers to maintain internal state and so on more easily. But then it does need to be installed. I heard long ago that the web didn't kill off client-server architectures because the web was better, it killed them off because you didn't need to install anything. So weigh application support costs into your equation. Also consider the capabilities of your development team (including their development aspirations - where they'd like to go) and the strategic focus of your company. Hope this helps, Michael Micheletti ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
