Jargons of Info Tech industry

John Bokma john at castleamber.com
Sat Aug 27 00:13:16 CEST 2005

Chris Head <chris2k01 at hotmail.com> wrote:

> John Bokma wrote:
>> Chris Head <chris2k01 at hotmail.com> wrote:


>> It can be made much faster. There will always be a delay since
>> messages have to be downloaded, but with a fast connection and a good
>> design, the delay will be very very small and the advantages are big.
> What advantages would those be (other than access from 'net cafes, but
> see below)?

And workplaces. Some people have more then one computer in the house. My 
partner can check her email when I had her over the computer. When I 
want to check my email when she is using it, I have to change the 
session, fire up Thunderbird (which eats away 20M), and change the 
session back.

[ .. ]

>> Each has it's place. A bug in a thick client means each and everyone
>> has to be fixed. With a thin one, just one has to be fixed :-D. 
> True. However, if people are annoyed by a Thunderbird bug, once it's
> fixed, most people will probably go and download the fix (the
> Thunderbird developers really only need to fix the bug once too).

Most people who use Thunderbird, yes. Different with OE, I am sure. With 
a thin client *everybody*.

>> Depends on where your mailbox resides. Isn't there something called
>> MAPI? (I haven't used it myself, but I recall something like that). 
> IMAP. It stores the messages on the server. Even so, it only has to
> transfer the messages, not the bloated UI.

But technically the UI (whether bloated or not) can be cached, and with 
Ajax/Frames, etc. there is not really a need to refresh the entire page. 
With smarter techniques (like automatically zipping pages), and 
techniques like transmitting only deltas (Google experimented with this 
some time ago) and better and faster rendering, the UI could be as fast 
as a normal UI. 

Isn't the UI in Thunderbird and Firefox created using JavaScript and 
XML? Isn't how future UIs are going to be made?

> I concede that Webmail
> might be just as fast when using a perfectly-designed
> Javascript/frames-driven interface. In the real world, Webmail isn't
> (unfortunately) that perfect.

Maybe because a lot of users aren't really heavy users. A nice example 
(IMO) of a web client that works quite good: webmessenger ( 
http://webmessenger.msn.com/ ). It has been some time since I used it 
the last time, but if I recall correctly I hardly noticed that I was 
chatting in a JavaScript pop up window.

> As I said above regarding 'net cafes:
> If the Internet cafe has an e-mail client installed on their
> computers, you could use IMAP to access your messages. You'd have to
> do a bit more configuration than for Webmail, so it depends on the
> user I guess. Personally I doubt my ISP would like me saving a few
> hundred megs of e-mail on their server, while Thunderbird is quite
> happy to have 1504 messages in my Inbox on my local machine. If I had
> to use an Internet cafe, I would rather use IMAP than Webmail.

I rather have my email stored locally :-) But several webmail services 
offer a form to download email.

>>>Thunderbird is faster as soon as the Internet gets congested.
>> Ah, yeah, wasn't that predicted to happen in like 2001?
> Wasn't what predicted to happen? Congestion? It happens even today
> (maybe it's the Internet, maybe it's the server, whatever...). Hotmail
> is often pretty slow.

I read sometime ago that about 1/3 of traffic consists out of bittorrent 
traffic... If the Internet gets congested, new techniques are needed, 
like mod_gzip on every server, a way to transfer only deltas of webpages 
if an update occured (like Google did some time ago). Better handling of 
RSS (I have the impression that there is no "page has not been 
modified" thing like with HTML, or at least I see quite some clients 
fetch my feed every hour, again and again).

John                   Small Perl scripts: http://johnbokma.com/perl/
               Perl programmer available:     http://castleamber.com/
            Happy Customers: http://castleamber.com/testimonials.html

More information about the Python-list mailing list