Richard Curzon
06-22-2000, 12:44 PM
The browser is perfect for the new eStores and corporate presence sites.
For more traditional apps hitting the internet, SOAP should provide an
industry standard model alternative to thin client.
Most existing desktop apps that migrate to the web probably shouldn't and
won't use the Browser as the interface. IBM, Oracle, and Sun marketing
(think of the millions they are spending!) is all to support the THIN CLIENT
as the only possible way to hit the web . From the people who milked you for
millions in the Y2K crisis, now there's the web server "bull stampede"
crisis. Bring your checkbook, and we'll solve your problems the expensive
"THIN CLIENT" way! <g>.
But what sense does it make to throw away today's humungous power available
on the client, and create expensive logjams on your server?
Hopefully between VB7, and SOAP/XML, we'll have a very simple and easy
paradigm for sensible partitioning apps between client and server, all in a
single project, a single deployment. Component upgrades via internet, as
well as downloading tables where it makes sense, all transparent and
automatic.
I wonder why more "portals" don't give their cusomters the IE5 WebBrowser in
a VB client, rather than a raw browser. Even a portal could make excellent
use of local computing power, as well as escape the sandbox. Some of the
base navigation through topics and subtopics could be downloaded and done
locally, finally hitting the server only when raw content is needed, e.g.
the way Compuserve frontends used to download some frontend stuff. The
server could support a lot more online games if local power was used. And
on the unethical side, think of all the information they could have "to help
you find the stuff your interested in". Scary.
Anyway... are we ready to move out of the age where THIN CLIENT dominates
industry head space?
--Richard
For more traditional apps hitting the internet, SOAP should provide an
industry standard model alternative to thin client.
Most existing desktop apps that migrate to the web probably shouldn't and
won't use the Browser as the interface. IBM, Oracle, and Sun marketing
(think of the millions they are spending!) is all to support the THIN CLIENT
as the only possible way to hit the web . From the people who milked you for
millions in the Y2K crisis, now there's the web server "bull stampede"
crisis. Bring your checkbook, and we'll solve your problems the expensive
"THIN CLIENT" way! <g>.
But what sense does it make to throw away today's humungous power available
on the client, and create expensive logjams on your server?
Hopefully between VB7, and SOAP/XML, we'll have a very simple and easy
paradigm for sensible partitioning apps between client and server, all in a
single project, a single deployment. Component upgrades via internet, as
well as downloading tables where it makes sense, all transparent and
automatic.
I wonder why more "portals" don't give their cusomters the IE5 WebBrowser in
a VB client, rather than a raw browser. Even a portal could make excellent
use of local computing power, as well as escape the sandbox. Some of the
base navigation through topics and subtopics could be downloaded and done
locally, finally hitting the server only when raw content is needed, e.g.
the way Compuserve frontends used to download some frontend stuff. The
server could support a lot more online games if local power was used. And
on the unethical side, think of all the information they could have "to help
you find the stuff your interested in". Scary.
Anyway... are we ready to move out of the age where THIN CLIENT dominates
industry head space?
--Richard