There is a well know effect related to the light speed limit. :-) Basically it adds some constant delay to all packets. This delay depends on physical wire distance between client and server. Even if you have infinite bandwidth, you will still experience delay. Retransmissions of packets and technical delays (e.g., waiting for ACQ) will compound it. (The latter one explains the speed difference between TCP and UDP packets.) That's why it is better to reduce number of communications between hosts to reasonable minimum. It reduces server load and network load, while improving responsiveness of user interactions. It's a must for some network implementation, e.g., satellite-based networks.
Obviously if hosts have limited bandwidth, it will introduce more delays. While it is possible to ignore this delay for specific applications, it's not a good assumption for all applications possible with Django. Thanks, Eugene "Simon Willison" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > On 17 Nov 2005, at 23:04, Christopher Lenz wrote: > >> I don't agree, at least for the common cases such as validating emails, >> URLs, date/time fields etc. It really shouldn't be necessary to call >> back to the server for trivial and/or common validation tasks. > > I don't understand why not. It's hardly a performance burden (the amount > of data being transferred is trivial) and it makes things on the client > incredibly simple as the validation logic for one field (send to the > server, see what it says) is reusable for every other field. Premature > optimisation is the root of all evil. > > If I get some spare time soon I think I'll build the Ajax-only validation > thing as a proof of concept. I'm willing to bet that the performance > difference between it and pure client-side validation will be > imperceptible in most cases. If it's noticable and obvious that the user > experience would be better with hybrid client-side/Ajax validation then > I'll throw my support firmly behind that option. >
