Archives
What's New
Site Map
Subscriptions

Home
NetFlash
This Week
Buyer's Guides/Reviews
Forums
Net Resources
Industry/Stocks
Careers
Seminars and Events
Product Demos/Info
Audio Primers

IntraNet


Error 404--Not Found

Error 404--Not Found

From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

















  • Choose Your LAN
  • ATM vs. Gigabyte Ethernet
  • Thin Clients & Java / ActiveX
  • Quality of Service
  • NetPC's and NC's
  • Intranet Do's and Dont's
  • Telecom trends
  • What's Hot!!
  • The complete text

  • Thin Clients & Java / ActiveX

    Pundits are talking about network-centric computing, meaning we'll shift from these heavy apps-laden desktops to thinner clients running Java and ActiveX applets. What's wrong with this story?

    Nolle: It's crap. It's nothing but a tired rehashing of the old diskless workstation concept. Dumb terminals can be replaced by semi-dumb network computers. Smart PCs won't be.

    Gibbs: Nothing is wrong with the story. But there are some problems with it. Migrating to thinner clients is complex and it will take quite a while for the leading application vendors to make any significant inroads into migrating their products to the new world order. And the NC thing is a nice idea but a little short on practicality - you don't dispose of an installed base in less than about three years, by which time the next generation of desktop applications will have come along.

    Unless Microsoft can't keep up the upgrade pressure, there's little reason to assume that IS will get so comfortable and complacent with PC software that they will have the time and will to go down a different path.

    Network computers are not the ultimate fix to improve efficiency and costs that some of the pundits would have us believe. Not all the problems of dealing with fat applications go away. For starters, NCs will demand much greater network bandwidth than current applications and the increased server processing and storage demands will be huge. Ya gotta spend the money ...

    Also, security, security, security. We don't know what the security implications are of either Java applets (as distinct from Java programs, which have nothing in the way of security enforced) or ActiveX, although the latter has a far less convincing story to tell than the former.

    Heckart: I'd rather say what's right with the story. We all know that the problem being addressed is a real one. We're tired of installing this year's software version only to have every last inch of disk space eaten up on our computer that last year was totally state of the art - especially when 90% of the functionality in those zillion lines of code aren't even used 98% of the time. Downloading what you need when you need it is a great idea.

    The critics in this idea seem mainly to be of two camps: the 'something-to-lose' category and the 'give-it-to-Mikey-he-hates-everything' category. Those not already positioned to benefit from network-based computing, or already supplying the competitive solution, can find lots of bad things to say about it. Just like we can find lots of bad things to say about the way it's done today. The other naysayers are often consultants, since we make money telling people why things won't work, or those that criticize every new idea until they see 'proof' that there is 'demand'.

    Every new idea has a lot of bugs that have to be worked out and the NC is certainly no different. What's exciting about NCs is that they could reshape the way networks are built, software is sold and network services are defined. And probably all for the better.

    Briere: I think people are overdramatizing this whole battle. We're working with some clients who are looking to create the next generation of fax devices for IP transport. These have elements of what you are talking about. Do we consider them 'thin clients' or 'slim PCs' or anything else? No, we consider them fax devices that solve a specific solution in the marketplace. Again, elements of a device can have different characteristics and the penchant for labeling things one way or another is annoying.

    The network is going to be centric for some tasks and non-centric for others. Taken as a market whole, one will 'win' out, but is that really important for a given user looking to solve specific needs? We've seen a global retailer evaluate NCs and a souped-up smart phone for the same task. Is one more net-centric than the other? It depends what you need that device to do.

    Kearns: Today's programmers don't understand tight code anywhere near as well as yesterday s did - say, 10-15 years ago or longer. What we're liable to see are today's apps broken into many, many modules. Users will spend lots of time waiting for each module to load across the net and will reject the technology.

    Bradner: There is not all that much wrong with the story other than it seems to assume an homogenous requirement domain. There seems to be some deep need to find one answer to all possible questions -- maybe because reality is too confusing.

    Clearly there are lots of places where the existing applications are dumb terminal or X-Window terminal-based and the thin-client/network computer model will work just fine. But there are many other places where the users are doing just fine doing local work on their local computers where the fit is not nearly as good.

    3a. Can applets be small, yet powerful?

    Nolle: Sure, if you believe that all the power of modern Pentium and RISC systems is really a cynical plot on the part of the chip vendors. If an interpretive language can build a superior application, a compiled language ought to do better. Java is still a computer language, remember. It doesn't do anything the hardware itself can't do, and any language that can exercise the hardware features equally well would do equally well.

    Gibbs: Yep. Distributed processing, messaging, informational functions, etc., are all hugely valuable applet functions.

    Heckart: Who cares? The better question is: Can small applet's deliver adequate, or even powerful, performance to a user? As long as the answer to this is yes - perhaps as a result of combining lots of applets - then all is goodness. I think applet's should have been called 'ant-lets'. Like an ant, one little applet is pretty powerful per inch of body weight or code lines. And they work great in groups.

    Briere: I hope some advertising firm did not get a lot of money to coin the word applet because I'm already tired of it. But the question again presumes a broad sweeping conclusion for all applets. If you need an applet to do a specific thing for you and the applet does it, then I'd say it's powerful. If you are trying to cram a full application into an applet or something as large, then I think you're going to be disappointed.

    Kearns: Sure, a small applet can do one (or two) things very, very well and can be used in a number of different applications - a spell checker, for example.

    Go to the next topic...


    Feedback | Network World, Inc. | Sponsor index
    How to Advertise | Copyright

    Home | NetFlash | This Week | Industry/Stocks
    Buyer's Guides/Tests | Net Resources | Forums | Careers
    Seminars & Events | Product Demos/Info
    Audio Primers | IntraNet