I've been working with application streaming for the past year or so and often when I go to other groups within Intel to try and convince them that streaming is the way to go - they ask me - why bother? They reason that they are moving more and more to web based applications so why would they implement streaming for the applications they might have left written in a client side language.
Well - that's a good question - but it's interesting that when I speak to the management team this is their response but when I talk to developers - they are very excited (usually) about this possiblity.
Why? Because most developers would rather develop in a language that is more robust than you typically get with a web application tool. They like the ability to have more control over the graphical experience for the user and the ability to do more powerful things within the language. The management team is looking at where current momentum is going and they don't want to change the direction. But should they?
Is there a compelling reason to move to more client based applications and away from web applications?
Should we have both in our toolkit? - If so - where should we use which one - why would we ever build more client based (not sure what to call this, where the execution of logic happens on the client) applications?
To evaluate this question I think it would be good to go back to why we started to move to web based applications in the first place - for those that have been around long enough to remember when all we had was client based execution of applications (after mainframes of course). Unfortunately I have been around for all of the above and have been working with applications the entire time (since 1976).
So I find this interesting - anyone else?
In my next entry - I will start to explore this question to see if we can build a case for moving to at least a more balanced view of where we put logic execution.
IT@Intel Blog
Previous Next
tamant
Unfortunately so am I (old enough to remember mainframes) and now we are moving back towards the mainframe concept with virtualization on the server - similar if not the same as what were called LPARs in the old days. The big difference is the user interface with the capabilities on the client - browsers were a way to move to the micro world without sacraficing some of the system management you were able to have on the mainframe although now its is very expensive because you have lots of servers with administrators trying to keep them all in sync. The charm of browsers has been that you could minimize the chatter between applications on a client and databases on the backend over a very slow network, plus you had to worry about updating code on thousands of clients (prior to browsers). Web apps allowed you to update code on a server and you've updated all of your users. However there are limitations to browsers and you suffer performance on the servers and waste capacity on the clients. Streaming addresses part of that and if a company uses web services in their applications they can address some of the data "chatter". This gets us a fair ways down the path to utilizing the robustness of client computing based applications for graphics and processing power while utilizing centralized application management and security. Then the big question is can you make them efficient enough from a data access perspective utilizing web services or just plain good coding practice. Hopefully so... But it will be interesting to see.
Why we started to move to web based applications in the first place is the proper question to ask. I am old enough to and was around when mainframes where working systems.I am interested to see how things evolve over the next few years with streaming.