Where is the Internet heading?

Guest_imported · Jan 21, 2000

I've noticed a trend toward integrating the Web with the O/S. I am thinking this trend will continue, and eventually we will be connected (or interconnected, if you will) to the internet at all times. First, I think our desktop enviroment will eventually (over the next 3-5 years) morph into the WWW, untill they are virtually inseperable. I can see the virtual hard drives allready out there, the technology is not caught up yet, but what with the new advances in technology everyday, eventually it will be almost as fast as our own O/S. So what we will have in five years, is a computer enviroment that is completely tied into the internet. Not only our desktops, but also our microwave, refrigerater, VCR, etc. Will be "hooked into" the net, which makes the thread "Devices everywhere" concievable, as we can keep track of nearly every device in our house, we can set the roast to cook at 5:00pm while we are at our friends house, and we can check the temperature (possible through our interlink watch) to make sure it is cooking right. We can have our dishwashers turn themselves on at such-and-such time, we can basically controll everything from one location, through our Interlink. 
John Vogel <a href=mailto:johnvogel@homepage.com>johnvogel@homepage.com</a> <a href=

http://johnvogel.homepage.com>My

HomePage</a> WebMaster - DataBase Administrator - Programmer

johnk · Jan 21, 2000

As a developer of business application software for smaller manufacturers and distributors I also see the www. type of user interface becomming standard. And that is no small concern as we are big in fat client tiers written in VB. 
 
One of our customers who is also a software developer and has incorporated some of our accounting modules into his vertical app has decided to add a browser enabled set of functions to be used only for viewing data. It will be only a short time until our customers demand full functionality using the web for connectivity. 
 
My local telco rep just called today to announce the availability of 1.5GB full time connection of my server to the the internet with no limit to how many of my LAN workstations can sign in concurrently, all for $59.95 per month. So much for earlier cost limitations on broad bandwidth connections. 
 
I agree fully with John V's sentiments. Not only will all data communications use the web, even LAN apps will need to have the web look to best serve our users. 
 
JohnK

JimConrad · Feb 24, 2000

Now we just need a way to write the code using a framework like Visual Basic or Access which can work with ALL the different browsers and web-servers and not need programers to worry about the "state" of the user connection. 
 
Seems like the web is similar to where we were 10 or 20 years ago with the mainframe and IBMs IMS system. Efficiency of the server is more important than the amount of time it takes to develop an application. Jim Conrad <a href=mailto:jconrad3@visteon.com>jconrad3@visteon.com</a> <a href= > </a>

JimHorton · Feb 24, 2000

I wonder if some of the thinking regarding the internet may be short-sighted. That is, what is the 'internet'? Instead of looking at it as an 'application' or a 'server', why not look at it as just a conduit? Why not ook at it as a way that a company or person can connect to their own private servers from anywhere in the world--it's a device, listed in the OS's device or directory list--a company maps it's servers (obviously with the proper security) on the internet, and any employee anywhere in the world can connect. 
Why lock a company into a browser-based, thin client app, which has many severe compromises (the SDI nature being one that bugs me in particular), just because that's how most people use this 'conduit' now? 
I guess I just I don't really see the big problem with a fat-client sales force tool, for instance. For example, a company needs a custom solution, not a canned, compromise-ridden app that anyone in the world can access (a browser). Disk space is cheap, the internet 'conduit' will simply allow a company's work force to see that company's server from anywhere in the world as if it were in the same room. The bandwidth is almost there now. Suppose the employee has a rented computer, for instance, so he doesn't have the fat client app on the machine--he downloads it in seconds, from the company's server, whereever in the world he may be. Security is obviously an issue but it is with anything. Can someone enlighten me (without getting deeply into multi-tiered app philosophy) on why, with broad bandwidth and cheap disk space, a thin client is so advantageous and fat clients will be dinosaurs? 
--Jim Horton

johnk · Feb 24, 2000

Jim H, 
 
I have a stake in the continued use of "fat" clients as we have developed many apps in that structure. However, ever I see the scales tipping towards thin clients. 
 
1. Even with broad bandwith the loading of big apps is not necessarilly efficient or automatic. In fact, we frequently still need to put hands on each workstation when we install upgrades. That may end soon, but will continue to be a concern. 
2. Network administration is more complex with fat clients. 
3. Fat client hardware costs more than thin. Strong server hardware costs continue to decline. One server for X clients. 
4. Thin clients can experience a dropped connection, then resume when reconnected. In LANs, only the servers need UPS's. 
5. Certain backup procedures are easier to discipline. 
 
A hurried response. What do others think?

JimConrad · Feb 25, 2000

One view (which I don't agree with) is that this is a way around "DLL Hell", where the fat client app overlays a newer DLL with an older version causing other applications to "break" since they are using features not supported in the older library. Jim Conrad <a href=mailto:jconrad3@visteon.com>jconrad3@visteon.com</a> <a href= > </a>

JimHorton · Feb 26, 2000

I too, have a stake in fat-clients and I see the trend towards thin as well. However, I saw a mini trend towards NC's (network computers), that died a very quick death. These died because, while they had all the advantages of a thin client, the main advantage (in my opinion) was that thin clients can perform well with very narrow bandwidth. This obviously was not an issue with a 10mbps ethernet. And, since narrow bandwith is an issue (for now) with a typical internet connection being 56K or mabye a t1 shared with 100 users, we see this trend towards thin client. 
 
Most of the advantages cited (johnk) are for the network admins. I truly believe that when the bandwidth issue dissappears, people are going to say (no offense to the network admins), "screw the admins, I want the flexibility of the fat clients". The cost issue is valid, but really, these NCs, which could see a resurgence if everything goes thin-client, were not priced much below a decent PC. I saw some dusty NC's at one office--often with a PC sitting next to it (!)--people want their own disks, etc, and, to look over the shoulders of many in my office, they want their Solitaire. (now there's an advantage to NC's--keep the games off the server!). 
 
--Jim

calahans · Feb 28, 2000

I think that we are going to have much more integration with the net. Lets not forget that the internet is not the world wide web. The internet is the infrastructure which the

http://www sits

on. I think that eventually we will have more VPNs using the internet to linking business togethor. 
 
There is already a huge push which is linking outside systems into our home, namely television. If you think then on top we have phone systems into our house, there is the start of an architecture for connectivity with devices in our house and the outside world. 
 
Fat client apps are dying. They'll still be around in a few years but they don't make sense. Eventually all programming will be based on the object/component architecture. Business will demand that program A can hook up with program B. I've heard that SAP now have standard APIs which allow them to hook easily with other programs.

JimHorton · Feb 28, 2000

Yes, that's what I had said in an earlier post: The internet is a conduit. The 'web' is just content--other servers, etc, and the browser just an app used to access this. That's sort of my main concern--everything seems to be moving to the 'browser', which is just so primitive and confining. Just because that's the first thing everyone is using to get around the internet, why should everything 'dumb down' (my opinion) to this lowest common denominator? 
 
If we want to attempt (what many feel is impossible) to make everything compatible, full integration, ie, so a sparcstation can run the same apps that a wintel machine can, then why not set sights higher than the browser model? The browser is so much less usable than a typical MDI windows or xwindows app, yet major companies are making substantial changes in their apps to fit this browser model. I understand the connectivity thing, but that goes back to my original point--the brower isn't what gives us connectivity, the conduit is what gives it to us. 
 
And, (I can't remember if it was in this thread or not) I had opined that, yes, the object/component architecture *would* be the best solution, but it can only work when there is a universally agreed-upon model--as opposed to the incompatible competing models that are being trotted out now, along with the sniping ceo's of the companies sponsoring these models and languages (java, in particular). Before that happens, businesses, while they may *want* full integration, are going to go for what works now. I see too many of my programmer friends spinning their wheels (in my opinion) trying to learn java, only to have profound changes in the language as verions change. I'll wait till it all shakes out, then I'll jump in and learn something that'll be valid for more than a few months. I've done my time on the bleeding edge. 
--Jim

calahans · Feb 28, 2000

I know what your saying Jim. We do need some form of agreed standards - I wonder if we'll get them. Your right about the browser being a limiting factor, but lets not forget that I can connect to your site and use your app without ever having to install any software (i.e. buying a book from amazon) - this is one hell of a bonus. 
 
Cal

MikeLacey · Feb 29, 2000

"Fat client apps are dying"... with respect, that is absolute tosh. 
 
We have two kinds of application developer today (it's my day for sweeping statements - indulge me). 
 
1) People like JohnK - class based, layers everywhere, COM++ etc. Developers like these write the world class apps and are as rare as.... - Well they *are* out there, but you don't get many of them. 
 
2) People like me - we write programs that have heard of OO but think it's a bit hard and probably a bad idea. We still think COM refers to a DOS device driver. We write apps fat enough to be called obese. Microsoft love us. 
 
I don't see that situation changing to be honest and Terminal Server (aka Winframe) just conspires to keep small app development the same as it is now. We all get a bit more OO and we all think - "really should get into multi-tiers" (and then get cold feet) every so often but then do nothing. It is too easy to stay as we are, I'm still jittering about putting some common functions into a DLL so that we can upgrade more easily (or is that "introduce errors across multiple apps&quot

. 
 
Mike 
Mike Lacey <a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a> <a href=

http://www.cargill.com/>

Cargill's Corporate Web Site</a>

johnk · Feb 29, 2000

Even though Mike clings to overweight clients while I'm trying to put mine on a strict diet, I agree strongly with his analysis of current reality. 
 
It's so easy for me to buy into some technology or the other and then favor that approach to solve what ever opportunity comes up. I think that's part of the human condition. Upon reflection I now feel that I have been on a 3+ year crusade to force feed a technology into my firm while other newer technology has reduced the expected benefits. 
 
Our whole move into multi-tier was triggered by a requirement to provide fast response times to remote users who were connected by dial-up (analog) phone lines. The VB3 very fat client modules killed us when serching through large numbers of table rows. To leave most of this functioning on the server we turned to learning classes, DCOM, etc. We are now good at it, and are beginning to experience substantial benefit. A lot from the structured encapsulation of code modules that can be called from nearly anywhere in our integrated business apps. 
 
But the original goal of providing fast response times to remote users is now served as well or better by technology that "traps" data streams going to the screen and recreates that action on the remote screen (and sends clicks & keystrokes back). Not to mention the option of using browser technology. 
 
What ever application software technology we use, the arrival of broad bandwidth communications, whether using internet or other communications services, greatly reduces the need to expend the considerable effort we have spent to reduce the volume of data going up and down the line. 
 
So Mike, you are right on. Maybe I am too? So many factors involved. It's hard to do in the midst of current deadlines, but I do still believe that structured multi-tier architecture is worth all of us keeping an eye on. 
 
Tip of the hat to all who take time to consider this stuff.

JimHorton · Feb 29, 2000

I think we could distill the current discussion into the phrase "Hit it with hardware". If we still had 4.77 mhz pc's, with a 10 Meg harddrive, quite obviously none of use, if we coded the way we do now, would be working (unless some of you still do assembler). Hardware has solved so many of our problems, like, 'how can we write an efficient application?' or, 'How can we keep memory footprint or disk footprint down?'. Hardware saved the day by saying we don't have to. It's a moral question, I guess, as to whether that's good or bad. Hardware, in the form of the high-speed fiber--with which most business (and home users, a bit later) will be connected to the internet soon--will also answer the questions about thin and fat clients. Pig out, guys! 
--Jim

MikeLacey · Feb 29, 2000

"but I do still believe that structured multi-tier architecture is worth all of us keeping an eye on" -- me too. 
 
Multi-tier apps - in some form or another - will probably provide the next way forward. (very likely in some way that will have JohnK and myself hitting our heads on the desk for following some blind alley) 
 
-ml 
 
P.S. Only a programmer would describe the question of memory footprints as a "moral question" <grin> Hi Jim. 
Mike Lacey <a href=mailto:Mike_Lacey@Cargill.Com>Mike_Lacey@Cargill.Com</a> <a href=

http://www.cargill.com/>

Cargill's Corporate Web Site</a>

calahans · Mar 1, 2000

Mike - I have worked for a company where we wrote apps which where all client based. We where quite happy plodding away at this. I had many horrible days where an app installed on machine a would not run on machine b. We had no reusability, sometimes it felt like I was writing the same app over and over again... 
 
Then I moved into a consulting firm. This company is young and ambitious. There are rigourous standards in place. There is a demand for component like code. The returns we have seen are phenominal. The reputation we have in development have put us as a lead in our market place. Having worked in the fat app architecture type jobs my eyes have been opened to the possibilities. 
 
I'm not just speaking about VB either. We are using components based ideas as an architeture. We use it across the board on our C++ and Java projects as well. 
 
Thats why I said they are dying, I think that if people start using this they won't turn back. However in saying that smaller companies can't afford it. From a programmer point of view its really excellent, you can write new functionality not the same app repeatedly. 
 
Cal

JimHorton · Mar 1, 2000

calahans, 
I've seen that both ways--most recently I was in an internal Java class at work, and the instructor had a sample app to practice with. Of 8 fairly identical (as far as hardware and os) machines in our training room, it ran fine on 4, the rest had some glitch or another--whether it was Java.jar not in classpath, wrong version of netscape, wrong java, etc. 
I agree that what you're going towards may be better, but so was (notice the premature past tense) the Mac, so was betamax, etc. I just see history as getting ready to repeat--a well written fat-client will serve customers well, and while the object component may be better to we programmers, the users (and decision makers) don't know or care about that. They may see a bandwith issue, but that's soon to dissappear. 
Once again, I believe a universally standard framework is needed before most people will start diving in to a component based architecture. 
--Jim

classicman · Mar 5, 2000

I agree with your statements that the Internet will become much more integrated into our lives, for example controlling appliances as was suggested. I think that the Internet will have a much more profound effect on the average person. Many people who are not exposed to the web will become almost dependant on it for services like shopping and online banking. 
 
With that said, I also see a negative aspect of what the Internet is transforming into. I have only been on the web for about 4 years. I believe that the web will become much more controlled by Government and Big Business. Not that long ago there was a vast amount of regulations signed into law by Congress. Recently, a judge in Utah made a ruling concerning one sites rights to make hyperlinks to another site that had copyrighted information. I believe the Internet will become heavily regulated and possibly taxed.

JimHorton · Mar 6, 2000

My biggest question, and I'm not being facetious, is: Who's paying for the airtime? All that traffic in the Bell phone network 'cloud' being generated has is tremendously larger--exponentially larger than the traffic generated pre-Internet. And each person is only paying an average of, say, 10-20 per month, as compared to $30~ per month for local phone, and possibly $100's for LD, yet those bills were from comparitavely minsicule traffic. I think one explanation may be that in never really cost ATT that much to maintain the cloud in the first place. When we find who's paying (probably not the government), then we know who has some right to regulate the internet, ie, not the government, but if big business is paying the lion's share, then we may not have as much room to complain if they exercise some control. Anyone have any thought on this? 
--Jim

classicman · Mar 6, 2000

Actually, I get charged on my phone bill every time I call into my isp. The charge may not be that much, but the phone company is still making money.

JimHorton · Mar 7, 2000

Exactly, but how much airtime do you generate with your ISP? And if your ISP # is within 8 miles, you probably don't get charged more than $20-$30 per month. Me, I don't leave the line open all day, but I probably generate 4 hours per day, but phone calls I probably don't do 4 hours a month (my wife however--that's a different story!). Yes, they're still making money, since I don't think theres alot of overhead once the connection is switched at the CO, but they're not making as much as they could be, and believe me, that fact is not lost on the Bells. 
 
Anyway, even though the isp # is local, most of the internet destination is 'long distance'. If I spent 4 hours a day of long distance phone calling, I'd be broke. And now, with NetToPhone, etc, I think the Bells are going to start panicking. Net Voice technology is getting better, and with a higher bandwidths, voice quality can be perfect, and you could make hours of LD calls per day for that same local phone rate. I don't know how it's going to shake out, but the piper is going to be paid somehow. 
--Jim

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Where is the Internet heading?

New member

MIS

Programmer

Programmer

MIS

Programmer

Programmer

Programmer

Programmer

Programmer

MIS

MIS

Programmer

MIS

Programmer

Programmer

Technical User

Programmer

Technical User

Programmer

Similar threads

Log in

Part and Inventory Search

Sponsor