Mitch,

As with everything else in c/s  programming, the underlying concepts of
conventional programming don't scale in general to web based c/s. It's why I
have a lot of reservations about procedural applications that are sending
huge SOAP messages back and forth in synchronous mode, or even in a mildly
asynchronous mode (one where the expectation of response is on the order of
seconds). There are ways around it -- caching commonly utilized data either
on the server or (if the information is exclusive to a given query) in an
asynchronous variable on the client, but in general these are methodologies
as much as technologies. This worries me somewhat, as it is easy enough to
use a technology without understanding the underlying methodologies, and I
can see tens of millions of poorly trained VB programmer wannabes writing
applications that can't scale worth a damn. This wouldn't be so bad on a
private network where bandwidth is generous, but in the sometimes singularly
limited environments of the Internet having that many systems all claiming
open or near open connections sumultaneously could potentially bring the
system to its knees.

--  Kurt Cagle
----- Original Message -----
From: "Mitch Denny" <mitch.denny@[...].COM> 
To: <DOTNET@[...].COM> 
Sent: Wednesday, January 31, 2001 5:01 PM
Subject: Re: [DOTNET] ADO.NET is scary.


>  This is one of the pitfalls of client server
>  technology. Its easy to do the sums and add
>  up the total computing power of your client
>  base and come to the conclusion that shifting
>  the workload to them is a good idea. This works
>  extremely well for client-server applications like
>  SETI@home where individual clients are not continually
>  polling the application server in short time intervals.
> 
>  When you implement that sort of design where the
>  client is copying live data back and from every
>  couple of seconds then that is bad news and it
>  doesn't scale.
> 
>  ----------------------------------------
>  - Mitch Denny
>  - http://www.warbyte.com
>  - mitch.denny@[...].com
>  - +61-414-610-141
>  -
> 
>  -----Original Message-----
>  From: dotnet discussion [mailto:DOTNET@[...].COM]On Behalf Of
>  Mark Boulter
>  Sent: Thursday, 1 February 2001 07:53
>  To: DOTNET@[...].COM
>  Subject: Re: [DOTNET] ADO.NET is scary.
> 
> 
>  Its not that any one client has more processing power its that a 1000
client
>  have
>  combined more processing power and that any one client is only doing the
>  work
>  for that one client and not for all clients (what the server does). The
>  issue with
>  pushing work to the client is that if you take this to its logical
>  conclusion you
>  end up with the first generation client server systems where the client
does
>  all
>  the work and the server simply gives the client data to process.
>  Unfortunately that
>  means typically shipping down all the data to the client and saturating
the
>  network
>  - imagine delegating the where clause in "Select * from Customers where
>  CUST_ID='ABC'"
>  to the client - light on server processing load very heavy on network
>  bandwidth
>  mark
> 
> 
> 
> 
>  -----Original Message-----
>  From: Robert Rolls [mailto:rrolls@[...].AU]
>  Sent: Wednesday, January 31, 2001 1:45 PM
>  To: DOTNET@[...].COM
>  Subject: Re: [DOTNET] ADO.NET is scary.
> 
> 
>  How does the client have the most processing power? is it because there's
>  only a single user.
> 
>  -----Original Message-----
>  From: Ed Stegman [mailto:elstegman@[...].COM]
>  Sent: Wednesday, 31 January 2001 5:52 PM
>  To: DOTNET@[...].COM
>  Subject: Re: [DOTNET] ADO.NET is scary.
> 
> 
>  You are absolutely correct.
> 
>  > Following that argument to its logical conclusion, it would mean that
>  doing
>  > all the processing on the Client Tier is the most scalable.  Certainly,
>  the
>  > client tier has the most processing power, now if only we had infinite
>  > bandwidth :-)
>  >
>  > Darrel
>  >
> 
>  You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
>  subscribe to other DevelopMentor lists at http://discuss.develop.com.
> 
> 
> 
****************************************************************************
>  ****
>  This email and any files transmitted with it are intended solely for the
use
>  of
>  the individual or entity to whom they are addressed and may contain
>  confidential
>  and/or privileged material. Opinions, conclusions or other information
>  contained
>  in/with this message are not given or endorsed by the Datum Group unless
>  otherwise indicated by an authorised representative independent of this
>  message.
>  If you feel you have received this in error, please contact the sender and
>  delete all related material from any computer.
> 
****************************************************************************
>  ****
> 
>  You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
>  subscribe to other DevelopMentor lists at http://discuss.develop.com.
> 
>  You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
>  subscribe to other DevelopMentor lists at http://discuss.develop.com.
> 
>  You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
>  subscribe to other DevelopMentor lists at http://discuss.develop.com.
> 

You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.