Article:		TAXI to the Future
Subject:		Client Side Processing Tips
Date:		2001-03-16 23:07:06
From:		Anand Bashyam Narasimhan
Response to: Good for TAXI ing data what about behaviour...
AS much as I would greatly appreiciate the idea behid TAXI and how you have showcased it through your example of Maps, it would help it if some amount of detail can go into it wherein you can discuss various ways of client side processing of the XML data say with respect to a Database ResultSet in mind

Previous Message

Up

Next Message

• Client Side Processing Tips
  2001-03-23 04:39:01 Big Rat
  
  I couldn't agree with you more, Tim. I have an application server which calls our legacy code via a scripting language I made myself (RatScript) and produces XML data streams from GET/POST requests. In the HTML pages I use MS-XML objects to load and process the XML via (mostly) XSL (sometimes straight DOM API calls) in Javascript to produce the HTML (in some cases VML).

  
  People say, what about Netscape and so on. I say "Let's do it first, see what the customers buy second, and worry about the past when we retire"

  
  Rat's Wish: XML DOM & XSL Transform as part of Javascript standard (then I don't need to rely on MS)

  
  BigRat@t-online.de
  
  

  • Brower vs Good old Multi-Tier Client Server
    2001-03-26 18:13:32 PK Y
    
    Hi guys,

    
    The idea of browser client is great on paper and does work for most, non-time critical, non data entry centric applications.

    
    The lack of many desktop integration features in a browser app. is just not fleasble in building feature rich clients, plus a lot harder to build compare to traditional clients, due to the various limitations of HTML and browsers.

    
    But the big problem that back-fire many many projects are, reporting and printing. No project is complete w/o reports, yet, HTML is just not rich enough to deliver high quality reports easily; the high customizability of browsers easily make your report looks supurb on one desktop but horrable on the other. And printing is just a no-no; come on boys, there is no 'page break' concept in HTML!

    
    And then here comes the much bigger problem - multi-casting; one major advantage for moving towards multi-tier client/server is that server can push data down to the clients, at real time. Right you can write java applet to do that but then you are writing a java application, downloaded and run in the client's browser.

    
    So what's the future? Thinking about it, all these web-browser / web-server things are nothing more than vendor provided middle-tier product. In the old days, we use RPC/Cobra/MQ to invoke server code; now, we use SOAP, SSL, HTML.

    
    What do we gain? Large part of the networking and server management code are done by the web-server; we only need to concentrate on building the core application. Because web-servers are so widely used, due to the internet gold rush, unlike the 'pre-Gen-X' middle-tier buggy products, they are tried and working.
    
    

    • Brower vs Good old Multi-Tier Client Server
      2001-04-03 07:10:57 Joe Golden
      
      Anumber of the reason you mention for why existing Web technolgy makes for bad multi-tier client server, is why Curl was created (www.curl.com).