Phineas and Ferb

The funniest cartoon (joining Sponge Bob, The Fairly Odd Parents) is now Phineas and Ferb.

Missing Greeks

So here's a question that plagues me: What happened to Catherine Alpha Jones through Catherine Epsilon Jones?

Stargate Is Moving Again

I've been experiementing with Google Sites and decided to try implementing a Sites-based version of Stargate. Now the new Stargate is well on it's way to being done. I have to say, it's not bad and I may just move to Sites as the “official site” for Stargate.

I like the ability to update the site from a web browser from any location. This is in contrast the the current method where I log into a server where my source files are located, edit the source, regenerate the page or pages, then upload them to various web servers.

There are also some nice “free” features like the Site Map and Recent changes. The ability to add a blog made Site News trivially easy to implement. An additional advantage is that pages are organized into a hieararchy. And, of course, site searching is built in.

I really lucked out on the fact that there is a Theme that is a nice match for my previous color scheme so it almost looks like an intentional next step in site evolution. I miss the light yellow color though, which was taken from the core of the M100 galaxy in the picture I use as a logo.

I was worried about how to implement my Email Me form, but this also turned out to be a quick solution with Google Docs Spreadsheet and a Form (which is integrated right into Sites). Further, it's possible to have the spreadsheet to notify you by email when it changes so, voila!, an email form!

I have to reluctantly admit that the changes in the new layout, somewhat forced by the Sites style, is probably more usable.

The biggest downside is that I'm manually having to copy over and edit the data. I can semi automate it and by copying HTML and directly editing HTML on the sites pages, it does go faster for some lists and such. Most of the work involves editing out the CSS references from my HTML snippets.

The next question is: What do I do with the old site? Should I set it to redirect to the new Sites location? (Probably). I'll put up a this-site-has-moved message with the new URL then later maybe just code a redirect.

Google Grand Opening in Lenoir, NC

Google had their grand opening event for their data center in Lenoir, NC.

News article
TV Video (requires Windows Media)

More Sender-Stored Email

I was thinking about sender-stored email again. It occured to me how you could throw away SMTP and implement a whole new protocol pretty easily. The idea is partly inspired by OpenID.

It's also inspired by the fact that, instead of an email address, I've been using a URL for a number of years. If you want to send me email (and I don't know you) you go to that URL and fill out a form.

User A at Site S wants to send email to user B at Site T.

Previously, A@S would send email to B@T. It would go to an outbound email server at Site S, then be relayed to the exchange server for site T, then perhaps relayed through multiple servers inside T's location, until finally it was delivered to an inbox on an email server. At some later point, Users B would read their email and retrieve the message from the inbox.

In the new scheme, user B doesn't have an email address per se. They simply have a URL. It can be some arbitrary URL or such as http://b.email.myplace.com, or some generic email site like http://b.email.com, or a corp address maybe like, http://x.corp.com/eng/b.

Now, when A sends email to B, A's client simply POSTs a message to the URL using HTTP. The message contains these fields:

• From - The sender's name and possibly return URL
  
• (optional) To Name - Who the message it to.
• Subject
• Message URL - The URL of the message we are sending

This brief information goes into T's ``inbox.'' This is the only information required to be stored on the recipient's site. This inbox can be a simple table of data.

To read the message from A, user B accesses the URL in the message. This allows retrieving the email message with all of its headers. I've listed them before but here are some of the immediate advantages.

• The recipient immediately knows who the message is coming from (because they get it from the source site). Based on the URL, if they decide it's spam, they can choose not to read it.
• The message doesn't travel over the network until the last minute, when it's read. It efficiently travels directly to the recipient and completely under the recipient's control.
  
• The message is stored once by the sender A.
  
• However, the recipient does have the option of keeping their own copy if they want to.
• Any attachments are naturally additional URLs to retrieve them. The recipient can verify if the attachments are from the same site or not.
• Encryption is easy: (HTTPS).
• Authentication of the recipient is easy (B has to sign into A's site).
• This uses existing protocols and infrastructure. Most work is done by web servers.

And there's this big advantage.

There's no message store-and-forward or routing. The recipient's address is a URL and the sender connects to it directly.

The only new software required here is two pieces. There is the software that is posted to and that displays a list of messages. There is also software on the sending end that allows the sender to compose an email message. Then when they send it, the message is put up on the web server (for retrieval by the recipient) and that address is then sent.

Of course, it's possible to write email clients that do all of this behind the scene and make the email-reading experience completely indistinguishable from what currently happens.

Now look at what Site T needs in order for it's occupants to recieve email. In the current implementation of email, the site needs massive amounts of storage to handle all of the messages that arrive on an hourly basis. Messages are stored seperately (sometimes) for each recipient.

With the new scheme, Site T could simply give each user a browser and would only need to store a table of received messages.

This idea could easily be phased in along side existing email and with a bit of coding, it could be done transparently to the user. The cost savings and efficiency gains would be huge.

References: My previous Email Ideas posting and