Re: Jargons of Info Tech industry

2005-10-12 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello? I don't think that should make any difference. I should be able
to visit absolutely any website on the Internet without any danger to my
computer or the data stored on it. Any browser which allows otherwise
has a bug. Javascript is not inherently a virus vector. Flawed
implementations might be; the language itself is not. Similarly for
anything else. In reality, with a properly-configured, good quality
operating system (probably a UNIX-type system), one ought to be able to
run full native code without any danger to one's computer or data
(think: under the NOBODY account on Linux).

Just my 1/50th of a dollar.

Chris

Gordon Burditt wrote:
[snip]
> Browsers don't read unsolicited web sites.  Email readers do, however,
> read unsolicited email, and email from downright hostile correspondents.  
> And I consider "web bugs" and similar tracking methods to be a danger
> for something that's supposed to be ONLY "formatted text".
[snip]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDTfb26ZGQ8LKA8nwRAo53AJ4gt1VeSkonnRC0f2eSdwLaJt85CACcDP5+
xVO8Y8uWFRzwY26H4EmmKDo=
=178i
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Jargons of Info Tech industry

2005-10-12 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thunderbird is nice that way. You can tell it to render HTML by default,
and even images if they're included in the body of the e-mail, but tell
it to NOT render anything which requires connections to external servers
unless you click a Show Images button. I think Hotmail does a similar thing.

Chris

Paul Rubin wrote:
[snip]
> That's the worst of all.  I certainly don't want my mail reader
> opening network connections to arbitrary places when I read my mail.
> I have no willingness at all to reveal my mail reading habits or IP
> address to everyone who sends me email.  If someone wants a return
> receipt, they can use snail mail and fill out a form at the post
> office for it.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDTfdO6ZGQ8LKA8nwRAuSGAJ4+U6oSZrrO500FptiEGuAYrtXZlwCfYpQP
1TEMkwZwjevSwh+GfR72BlA=
=Xpel
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Jargons of Info Tech industry

2005-08-25 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
[snip]
> ... and generally these "web based message boards" (i.e. forums I
> assume you mean) have none of the useful tools that Usenet offers and
> are much, much slower.
[snip]

Arrgh, I *emphatically* *hate* Web-based-(almost anything). Why, oh WHY,
would we subject ourselves to Web-based message boards and Webmail
services? When using a proper e-mail client, your bandwidth usage
consists of downloading your e-mail. When using a Webmail service, your
bandwidth usage consists of downloading the message, PLUS the entire
user interface. Additionally, a user interface operating inside an HTML
renderer can NEVER be as fast as a native-code user interface with only
the e-mail message itself passed through the renderer. I mean, the way
Webmail works, you're at the message list and click on a message to
view. This causes a whole new page, user-interface and all, to be
loaded. In comparison, that's like shutting down and re-opening your
e-mail program for every single message you want to view!

Why can't we use the Web for what it was meant for: viewing hypertext
pages? Why must we turn it into a wrapper around every application
imaginable?

...



Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDDoRR6ZGQ8LKA8nwRAvinAKCVi3Sfztpm3ILUk7TnunPJxBEVzwCguvAu
ME8mWt2eVNpPUckJ3NT39KY=
=TdTk
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Jargons of Info Tech industry

2005-08-25 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Bokma wrote:
[snip]
>>usage consists of downloading your e-mail. When using a Webmail
>>service, your bandwidth usage consists of downloading the message,
>>PLUS the entire user interface.
> 
> 
> Not necessary when using (i)frames + cache

True. Perhaps Hotmail is not very well designed, but it doesn't use
frames. I'm not really familiar with other Webmail systems, but the one
provided by my ISP doesn't either.

> 
> 
>>Additionally, a user interface operating inside an HTML
>>renderer can NEVER be as fast as a native-code user interface with
>>only the e-mail message itself passed through the renderer.
> 
> 
> Nowadays, more then futile.

Sorry, I don't understand what you mean. Even on my 2.8GHz Pentium 4,
using Thunderbird to juggle messages is noticeably faster than wandering
around Hotmail. Complex HTML rendering still isn't absolutely
instantaneous. It's significantly more painful when I use my 433MHz
Celeron. It simply takes a long time to jump between message, inbox,
other message, inbox, other other message, inbox, etc.

> 
> 
>>I mean, the way
>>Webmail works, you're at the message list and click on a message to
>>view. This causes a whole new page, user-interface and all, to be
>>loaded. In comparison, that's like shutting down and re-opening your
>>e-mail program for every single message you want to view!
> 
> 
> This can be designed much better by using iframes, maybe even Ajax.

Agreed. Judicious use of frames (internal or otherwise) or
Javascript-based partial reloads could seriously improve the situation.
They might also provide an easier way for Webmail providers to implement
their pages in valid HTML: if you render the entire e-mail message alone
 in a frame, you don't have to start stripping out pieces of e-mail
because they already exist (html and body elements, for example)

> 
> 
>>Why can't we use the Web for what it was meant for: viewing hypertext
>>pages? Why must we turn it into a wrapper around every application
>>imaginable?
> 
> 
> Because it works?
> 

... and purpose-built client applications (e.g. Thunderbird) don't?
Maybe I'm old-fashioned but I still very much prefer thick clients. They
simply feel much more solid. Perhaps part of it is that thin clients
have to communicate with the server at least a little bit for just about
everything they do, while thick clients can do a lot of work without ANY
Internet round-trip delay at all. Hotmail has to talk to the server to
move a message from one mailbox to another. Thunderbird doesn't. Ergo,
Thunderbird is faster as soon as the Internet gets congested.

Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDDqXh6ZGQ8LKA8nwRAsVyAKCjwP9iyrPRBnMsI1pB+wqZdANE6ACfYeGx
w8SLwXln0VjpuwF+L7BDfKM=
=pZ/B
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Jargons of Info Tech industry

2005-08-26 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Bokma wrote:
> Chris Head <[EMAIL PROTECTED]> wrote:
> 
> 
>>John Bokma wrote:
> 
> 
>>>>Additionally, a user interface operating inside an HTML
>>>>renderer can NEVER be as fast as a native-code user interface with
>>>>only the e-mail message itself passed through the renderer.
>>>
>>>Nowadays, more then futile.
>>
>>Sorry, I don't understand what you mean. Even on my 2.8GHz Pentium 4,
>>using Thunderbird to juggle messages is noticeably faster than
>>wandering around Hotmail. Complex HTML rendering still isn't
>>absolutely instantaneous.
> 
> 
> 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)?

[snip]

>>... and purpose-built client applications (e.g. Thunderbird) don't?
> 
> 
> if A -> B, it doesn't say that B -> A :-) I.e. that it works via HTML
> doesn't mean it doesn't with a dedicated client ;-). 
> 
> I live in Mexico, most people here rely on so called Internet cafes for
> their connection, and even the use of a computer. For them Thunderbird
> *doesn't work*. 

This point I agree with. There are some situations - 'net cafes included
- - where thick e-mail clients don't work. Even so, see below.

> 
> 
>>Maybe I'm old-fashioned but I still very much prefer thick clients.
>>They simply feel much more solid. Perhaps part of it is that thin
>>clients have to communicate with the server at least a little bit for
>>just about everything they do, while thick clients can do a lot of
>>work without ANY Internet round-trip delay at all.
> 
> 
> 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).

> 
> 
>>Hotmail has to talk to the server to
>>move a message from one mailbox to another. Thunderbird doesn't.
> 
> 
> 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. 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.

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.

> 
> 
>>Ergo,
>>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.

> 
> Also, unless you have some program that kills spam on the server, you 
> have to download all with Thunderbird. I remember a funny day when I got 
> 2000 messages/hour due to a virus outbreak :-( With hotmail, if you have 
> 100 new messages you download them when you read them. Or kill them when 
> you don't want to read.
> 

Fortunately I'm not plagued by spam. I get around 150 messages per day.
Of those, about 140 are from a mailing list, 5 are personal, and 5 are
spam. I used to get about 100 messages per day of which 90 or so were
spam, but it suddenly stopped. To this day, I have not figured out why.
Nevertheless, I agree that not having to download all those messages is
one place where Webmail blows POP out of the water (but IMAP, which
could be a sort of "middle ground", doesn't suffer from this).

Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDD0eM6ZGQ8LKA8nwRArpyAJwJ+W2Q2H2wZLrcNcj8Z70sCoBIswCfZZUV
DaaHKbqfADYKOWAE9APey7w=
=6Mmv
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Jargons of Info Tech industry

2005-08-27 Thread Chris Head
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Bokma wrote:
> Chris Head <[EMAIL PROTECTED]> wrote:
> 
> 
>>John Bokma wrote:
>>
>>>Chris Head <[EMAIL PROTECTED]> wrote:
> 
> 
> [HTML]
> 
> 
>>>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.
> 
> [ .. ]

Hmm. That would just be a matter of preference. Personally I moved my
Thunderbird profile into a shared directory and pointed everyone at it.
Now only one login session can run Thunderbird at a time, but any login
can see everyone's mailboxes.

> 
> 
>>>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*.

True. As a programmer I don't usually think about the people who never
download updates. The way I look at it, if somebody doesn't have the
latest version, they shouldn't be complaining about a bug. I guess thin
clients could be taken to mean you have a very light-weight auto-update
system ;)

> 
> 
>>>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 believe it is. I'm not sure if it's a good idea, but that's neither
here nor there.

> 
> 
>>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.

Haven't ever needed to use that program.

> 
> 
>>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.

I've not seen a service that allows that. Sounds nice.

> 
> 
>>>>Ergo,
>>>>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 te