Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Computer History Museum Makes Eudora Email Client Source Code Available

globenewswire.com

Post reply on HN
Print view View original

111–120 of 152 posts

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#111

Post by [deleted] »

mirimir wrote: post #102
behringer wrote: post #100

Earlier quoted context omitted.

But the email is readable, it has a link to a message online. It is not a change to the standard, since it's in the body, where you can write whatever you like. In fact, it's not even unprecedented, because Cisco has been offering this exact same type of system for years generally for PHI and other sensitive uses.

A URL, or embedded content as part of HTML? If it were just a URL, even an HTML-enabled client would show just the link. I assumed that it must be embedded content, which would be rendered as a normal-looking message. Maybe it's both. But even so, I'd just see the link. And generally, I ignore blank messages containing links. Also, it's not uncommon for email list software to strip HTML, and I doubt that it would dec…

[deleted]

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#112

Post by hsivonen »

cge wrote: post #99
justin66 wrote: post #18

Earlier quoted context omitted.

> The license you were forced to accept I didn't accept it. I'll try to get them to remove those terms, that appeals to me more than agreeing to legal terms I don't intend to abide by.

It's possible they have responded to this, because I now have these terms come up: Copyright (c) 2017, Computer History Museum. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted (subject to the limitations in the disclaimer below) provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this…

That license does not match https://opensource.org/licenses/BSD-3-Clause

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#113

Post by torstenvl »

romwell wrote: post #78
behringer wrote: post #72

Earlier quoted context omitted.

One of the commenters on that article wrote: > Well, I think this works differently. The email just includes a link to a Google webpage with the email. It’s still just an email sitting in your inbox. It doesn’t remove itself automatically. So it's not a standards issue at all.

It's an abuse of the standard. The email standard was built so that you can check your email with a client, and view the contents offline at your convenience, archive, back up, etc. Google's email proposal kills this functionality. When was the last time I used this, you may ask? On Saturday. I was in one of the slot canyons in Utah with zero signal, and, while taking a break, I wrote several emails in my Opera email…

How do you distinguish between this and, say, e-cards? Blue Mountain has been sending e-mail links to ephemeral content since at least the early 2000s.

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#114

Post by hsivonen »

jcranmer wrote: post #48
toyg wrote: post #26

Earlier quoted context omitted.

It's a bit weird, just above they say "they decided not to simply grant a license, but to transfer ownership of the code, the Eudora trademarks, the copyrights, and the Eudora domain names to the Computer History Museum". So it's the CHM who is barring people from using the name. The relevant clause must be this: "Neither the name of Computer History Museum nor the names of its contributors may be used to endorse or…

> Is this really "BSD license", if the name is off-limits? This looks like an extra clause to me. There's actually a few licenses that are called the BSD license. In modern terms, BSD refers to the 3-clause BSD. However, the 3-clause BSD was not the original form. It was introduced because the 4th clause was generally viewed as problematic. That 4th clause is: > 4. Neither the name of the nor the names of its contrib…

The all caps part has an extra sentence, too.

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#115

Post by glandium »

throwaway76543 wrote: post #109
kps wrote: post #101

Earlier quoted context omitted.

Why is POP3 horribly inefficient? Lack of an equivalent to the IMAP COMPRESS extension?

It's fine if it's used to simply pull down mail to a local spool. The inefficiency complaints usually stem from attempting to maintain mail on a remote server across multiple clients. POP3 does not implement a sufficiently rich protocol to make this possible without downloading the entire spool onto each client. For example, no searching.

No, it's highly inefficient in the face of latency, because there essentially is no batch fetching primitive. Fetching messages over a high latency connection (e.g. to a server on the other side of Earth) takes forever if you have a lot of messages.

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#116

Post by throwaway76543 »

glandium wrote: post #115
throwaway76543 wrote: post #109

Earlier quoted context omitted.

It's fine if it's used to simply pull down mail to a local spool. The inefficiency complaints usually stem from attempting to maintain mail on a remote server across multiple clients. POP3 does not implement a sufficiently rich protocol to make this possible without downloading the entire spool onto each client. For example, no searching.

No, it's highly inefficient in the face of latency, because there essentially is no batch fetching primitive. Fetching messages over a high latency connection (e.g. to a server on the other side of Earth) takes forever if you have a lot of messages.

That's addressed by pipelining (rfc2449, published back in 1998). No batch primitive is necessary if the request/response sequence isn't serialized.

The lack of a remote manipulation interface has always been a problem, however.

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#117

Post by [deleted] »

52-6F-62 wrote: post #74
edmanet wrote: post #11

Damn. The "bad" words have been sanitized. Seeing the programmers' frustrations as they appear in the comments enhances the experience when viewing old code like this.

There are some choice function names in `anal.c` (Mac) void AnalScan( void ); It's clearly short for 'analysis', but the child in me couldn't not.

[deleted]

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#118

Post by glandium »

hsivonen wrote: post #112
cge wrote: post #99

Earlier quoted context omitted.

It's possible they have responded to this, because I now have these terms come up: Copyright (c) 2017, Computer History Museum. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted (subject to the limitations in the disclaimer below) provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this…

That license does not match https://opensource.org/licenses/BSD-3-Clause

It matches https://spdx.org/licenses/BSD-3-Clause-Clear.html

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#119

Post by tambourine_man »

mrpippy wrote: post #63
yuhong wrote: post #60

It would be fun to port the Mac version to x86.

The Mac archive doesn't have any resource forks, which is likely going to prevent building a working copy. Trying to figure out who to email at the CHM about it.

There may be hope:

https://twitter.com/siegel/status/999077760244084736

Re: Computer History Museum Makes Eudora Email Client Source Code Available

#120

Post by eitally »

swasheck wrote: post #110
bdamm wrote: post #20

Earlier quoted context omitted.

This is beautiful. One of the "so obvious it's invisible" truths of the modern age, and I nearly forgot that Eudora and other pioneers of the age were making a somewhat risky choice to only support standard protocols and eschew the proprietary mailers. Most of them are now long dead yet POP3, IMAP, SNMP chug along. At the time, though, it wasn't so clear.

Wait. SNMP or SMTP? I'm legitimately asking and not being pedantic because I'm genuinely curious.

SMTP.
Post reply on HN