I am currently using my experience with milonga.be to build a similar site for Tango in Bulgaria. One of the major components of the site is the tango calendar. In this case I have chosen not to use a special iCal visualisation tool (more on that later in a series posts on Tango2.0), but just the standard Google Calendar IFRAME-based widget.
It’s not a bad widget, but it’s too limited. You can only display “Day/Week/Month/Agenda” style, the colors and fonts are fixed and it does funny stuff for events that continue after 12:00AM (which tango events regularly do, believe me).
I’ve already talked about the fact that iCal is a sissy format and that Gcal needs some more features. I was just thinking that it would be nice if some company would jump on that and provide the whistles and bells for iCal/vCal feeds (like those of Google Calendar), just like Feedburner did with RSS/podcast feeds (and they got bought by Google, so maybe their idea wasn’t half bad). So I introduce the following concept: CalendarBurner (since the Calburner/iCalburner domains are taken).
Continue reading CalendarBurner: Feedburner for iCal calendars
In order to send an email over SMTP, you need 2 sets of information:
- WHAT: the content of the email, i.e. from-address, subject, to/cc addresses and the actual message (in TXT and/or in HTML)
- HOW: you also need the name/address of an SMTP server (and its SMTP port), and optionally a username/password to authenticate to the server (ESMTP) – these would typically be fixed for the email sending application.
On the other hand, you have the HTTP GET format where you can put everything you need to execute the request in 1 string:
http://james:email@example.com /hr /request /?type=holiday&start=2004-11-22&end=2004-11-24
No need to save the ‘server/port’ data separate from the ‘request’ location or from the actual content.
Which inspired me to a similar format for sending email:
smtp://[username[:password]]@server[:port] /from:address [/subject:text] [/to:address] [/cc:address] [/bcc:address] [?[subject=text] [&message=text] [&to=text] [&cc=text] [&bcc=text] [&attachment=file]]
- smtp://relay.example.com /from:firstname.lastname@example.org /subject:Test+was+OK%21 /to:email@example.com /?message=Here+I+am%21
- smtp://localhost:2525 /from:firstname.lastname@example.org /subject:webserver+3+is+down ?email@example.com&message=webserver+3+is+down+(time-out+after+10+seconds)
- smtp://james:password@localhost /from:firstname.lastname@example.org /subject:this+is+authenticated /to:email@example.com
Keep in mind: a URL is typically limited to 255 characters (depending on implementation), and a querystring (the part after the “?”) is limited to 4KB.
- Out of principle, the from address should always be specified as the 1st level pseudo-folder
/from:address/. Because it should never be longer than 100 characters, and there should always be one, and only one.
- If your subject is more than 200 characters, you need the
?subject=text notation. Otherwise the
/subject:text/ is preferable because you would be less inclined to specify more than 1 subject.
- If your message content is more than 200 characters, you need the
?message=text. If you need more than 4KB, you could use the equivalent of a HTTP POST, i.e. not specify it in the URL string, but stream the whole this after giving the request.
- You could allow multiple
/cc:address/ entries, or just use a
- to allow ‘pretty’ email addresses, you could allow
/from:firstname.lastname@example.org:Peter+Forret/. (Any better suggestions for that?)
- You could allow a
smtp://default/... if you still want your email sending application to choose its SMTP server.
- Attachments can be specified with an address on a local disk, or on the Internet (with another URI)
The advantages of this system?
- you can specify a complete email in 1 single text string (with size limitations)
- one could easily specify a lists of emails to be sent (e.g. a text file with 1 email per line), and use different SMTP servers for some of them (e.g. send the Hotmail/MSN ones directly to mx?.hotmail.com for speedy delivery)
- it can be interpreted by the SMTP client (email sending application), that translates it into a regular SMTP conversation (
HELO ... MAIL FROM ... RCPT TO ... DATA)
- it could easily be accepted by a web server, that accepts the URI with the
smtp:// replaced by
http://. One could send an email by just clicking on a link in a browser. The server would of course not accept these requests from anyone, otherwise it would be an easy spam machine. But one could send emails with cURL or WGET. How about that?
- if a company stores all sent messages on a special server, you could have a search-within-your-emails-site with +- the same URI format:
http://peter:email@example.com /from:firstname.lastname@example.org /?subject=*contract* ¬before=2004-11-15 ¬after=2004-11-20 &to=*robert*
- One could also adopt
smtps:// for SMTP over TLS.
If anyone can do something useful with this, be my guest!