I really like the Firefox toolbar search box, but I hate how it essentially ties you to a single search engine. Sure, you can get plugins for just about every site out there that's searchable, but to switch engines, you have to use the mouse, click a couple of times, and then bring your hand back to the keyboard to type in your query. That's way too much work.

So, I created my dream search box plugin. Basically, you can prepend queries with prefixes to specify which site/service you want to search. For example, if you prefix your query with "amazon:" it'll send the query to Amazon, use "ebay:" and it goes to eBay, and so on and so forth for a dozen or so supported sites. You can also set your own prefixes, so I can just type "d:" to search Dictionary.com or "p:" to search PHP function docs. Of course, you can search without specifying a prefix, and it'll go to your default search engine (it's Yahoo by default, but you can set it to whatever you want). To top it all off, you can add your own search query if it's not supported by default, by sending a simple query.

Read about it and download it here.

Now that I'm out of school, I've been trying to catch up on some reading, and I've been keeping a slowly growing reading list to ensure that I don't actually catch up (but then, seeing how I still never get around to reading much, that doesn't seem to be that big of a problem).

Anyway, up until tonight, I've just been maintaining a wish list as a text file on my PowerBook. But, since that's so Web pre-alpha, I decided to upgrade to Web 1.0 by creating an Amazon wishlist.

So that was cool for all of about 5 minutes, but I decided to upgrade to Web 2.0 and do something cool like import my Wish List RSS feed to my 360 profile. Except, I couldn't find the damn RSS feed anywhere... and I still haven't found it. They have an RSS page, but no mention of wish lists there. So I looked on the big wide interweb, and found a 3rd party site that does RSS 0.91 (ugh), and another one that simply doesn't work.

Well, I figured it was, yet again, time to do some RYO. Fast forward a couple of hours, and I ended up with a hack that uses an AWS and spits out your wishlist as an RSS 2.0 feed. It's pretty skeletal, but well, it works:

http://www.openhive.com/wishlist.php?id=Z2X5CRD0C6BW

If any one else finds it useful, you're welcome to use it. I won't guarantee that it'll always work, or that it'll work forever, but, eh, welcome to Web 2.0. All you have to do is replace the 12-character ID with your own wishlist ID (which should be burried in any URL that points to your wishlist).

The feed aggregator I've been talking about is starting to take shape, and I feel like I've gotten to the point where I can share some more info. It's called FeedMuncher, and as previously hinted, the main objective has been to create an Open Source feed aggregator server and client that communicate using a new (soon to be) proposed open API. This API, tentatively called FAAPI (Feed Aggregation API --not very sexy, I know), can allow clients and servers to interoperate and synchronize feed aggregation meta-data, which in turn gives users the freedom to choose and switch between aggregator clients with minimal loss of data.

The current sample client is a single XHTML file (with 3 JavaScript includes) which, once loaded, communicates with the server solely through XMLHttpRequest using FAAPI. Anyway, see extended post for screen shots, and contact me if you would like to be notified when a public demo is available.
Show Rest of Post
[Tagged: feedmuncher feed+aggregators ]

Brad (of livejournal of SixApart) announced Yadis today. From the site:

This is yet another distributed identity system, but one that's actually distributed and doesn't entirely crumble if one company turns evil or goes out of business. A yadis-enabled site/blog lets you authenticate using your existing login from your homesite (whether that's on your own server or a hosted service) without giving away your password to the 3rd-party site you're visiting, or making a new account there, or giving away your email address.

I spotted the blog post I've been dreading for the past couple of weeks: New browser-based aggregator turns on. Why have I been dreading such a product launch? Because I've been working on something similar, and I was hoping I'd be the first at doing something... for once.

What I've been working on is also a browser-based feed aggregator, where the client is 100% DHTML and communicates with the server using a REST-like API (invoked through XMLHttpRequest). I'm not sure if FeedTagger is going in that direction, but IMHO, that API the client uses to communicate with the server is far more significant than the client or the server alone (or even together).

The API I'm designing, if adopted widely (a big if, I know), could do for feed aggregation what IMAP did for email. Such an API will make the whole web-based vs desktop feed aggregator decision unnecessary, as much as the desktop email vs webmail choice is moot when using something like IMAP (or even MS Exchange) to sync your mailbox; you can use any client (or server) you want, without (or with little) loss of (meta)data.

Anyway, I wasn't going to talk about all this until I had a fully functional prototype and the API was fully documented, but hey, the cat got out of the bag prematurly. In fact, if it weren't for scav, you'll probably be looking at a functional demo by now (with full source!). Alas, you'll have to wait a few more days.

The ambiguity in this post's title is actually quite appropriate, since that is exactly what I hate about dates. You'd think there'd be some structure to it, but then you come across a date that just fucks everything up.

Still don't know what I'm talking about?

Well, if you're expecting me to go on a tirade about my romantic life, you're going to be disappointed. I'm not talking about those yummy fruits either (I like those). No, I'm talking about these dates:

Thu, 21 Apr 2005 00:13:28 GMT

Dates in a format more or less like the above can be seen every where on the internet, from email headers to HTTP headers to RSS (2.0) feeds. So how is it ambiguous? Well, it's not syntactically/lexically ambiguous. After all, such date formats are well documented using unambiguous ways that look like:

     date-time   =  [ day "," ] date time        ; dd mm yy
                                                 ;  hh:mm:ss zzz

     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
                 /  "Fri"  / "Sat" /  "Sun"

     date        =  1*2DIGIT month 2DIGIT        ; day month year
                                                 ;  e.g. 20 Jun 82

     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"

     time        =  hour zone                    ; ANSI and Military

     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
                                                 ; 00:00:00 - 23:59:59

     zone        =  "UT"  / "GMT"                ; Universal Time
                                                 ; North American : UT
                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
                 /  1ALPHA                       ; Military: Z = UT;
                                                 ;  A:-1; (J not used)
                                                 ;  M:-12; N:+1; Y:+12
                 / ( ("+" / "-") 4DIGIT )        ; Local differential
                                                 ;  hours+min. (HHMM)

Thu, 21 Apr 2005 00:13:28 CET

To a human, it looks more or less identical to the first example. At least, it doesn't look like it should be an invalid date string. But it is. According to the specs I pasted above, "CET" is not a valid zone enumeration, and my software shouldn't have to recognize it. Lets look at more examples. Take a look at the following date strings, and let me know if they comform to the same standards:

Thu, 21 Apr 2005 00:13:28 GMT
Thu, 21 Apr 2005 00:13:28 -0600
Thu, 21 Apr 2005 00:13:28 EST
Thursday, 21-Apr-05 00:13:28 GMT

To most people, they look more or less equivalent. To a machine that strictly implements documented standards (as much as RFCs can be considered standards) the 3 are very different. The first two comform to RFC 2616 (HTTP 1.1), RFC 822, as well as RFC 2822, which technically obsoletes RFC 822. How 'bout the 3rd one? It's fine for RFC822 and 2822, but doesn't comform to 2616 because the only enumerated timezone permitted there is "GMT". The 4th one is obviously the odd ball here, but it actually comforms to RFC 2616.

The bottom line is, this mess makes date parsing a real pain. For example, if IlohaMail gets a message with a date format that looks like the second example, and fails to adjust properly for timezones because it doesn't know what "CET" is, users complain. And they're not going to accept "the date in your email doesn't comform to standards" as a valid excuse, largely because as far as any one can see, it looks like any other valid date string.

The good news is that people have learned. Sort of. Atom uses a very machine-readable date format. On the other hand, RSS 2.0 which, I believe was designed around the same time as Atom, uses RFC 822 (which, as I mentioned earlier, was obsoleted by 2822).

I implemented an AJAX interface to IlohaMail's message listing so that common operations like deleting, flagging, moving, and applying filters can be performed without reloading the page. I need to find out which browser+versions work so I can ensure the DHTML interface only gets served out if the user is on a compatible browser. (Read extended text for testing instructions.)
Show Rest of Post

I added a feature in IlohaMail to publish one's calendar, and to take it one step forward, decided to look into exporting to iCalendar files ('cause then I can import my schedule to my iPod). If I limit to just supporting portions of the format that's also supported in IlohaMail, it doesn't look too bad... except for one thing: VTIMEZONE.

In iCal, timezone information is specified in a VTIMEZONE component, which basically includes timezone offsets for both standard and daylight savings time. So far so good. But where it gets complicated is that VTIMEZONE understandably also wants to know when daylight savings time starts and ends. That is a huge problem, because different time zones (and even regions within the same timezone) have different rules as to when DST begins and ends (which, in extreme cases, changes from year to year). In other words, as far as I can tell, there's no algorithmic solution to this problem.

From what I've discovered, there's a fairly extensive database, commonly known as the Olson Timezone Database. You can then use a nifty program called VZic to convert the data into Outlook-compatible iCal files. All I have to do now is include the compiled VTIMEZONE data in IlohaMail (which'll add about 22k targz'd), get the appropriate region information from the user, and include the appropriate file.

Moral to story: time zones are a bitch. Now I understand why the Swatch Internet Time was conceived of to start with...

One thing that really annoys me about all web-apps (other than IlohaMail, AFAIK) that require users to be logged in, is that they generally only support one session per browser. Even GMail only supports one session, so whenever a friend borrows my laptop to check their accounts, they first see my mail, then have to log me out, log themselves in, and half the time forget to log out so I see their mail when I open up GMail again.

Supporting multiple sessions is NOT hard. If I did it with IlohaMail, so can anyone else.

(In case anyone's wondering why I use GMail in the first place... well, I don't, except as offsite backup, and as a reference for IlohaMail's prototype DHTML interface.)

I spent all night last night (literally) working on DHTMLizing (or GMailifying, if you prefer) IlohaMail. I'm starting with the message listing, which is about half way complete. At the moment, I can flip through pages, do a "quick search", apply filters, all without reloading the page (i.e. just through XMLHttpRequest). Some thoughts...
Show Rest of Post

Hula is a new OpenSource "non-groupware" mail/calendaring server project essentially based on Novell's NetWare. The project aims to be an Open Source version of GMail, concentrating predominantly on offering a sexy UI rich in JavaScript/DHTML.

Funny thing is, after tinkering with XMLHttpRequest, I've been thinking about redoing IlohaMail with a GMail-style DHTML interface myself. So what does Hula mean for IlohaMail2? Fortunately, Hula and a DHTMLized IlohaMail have similar goals, but vastly different target markets. From what I can tell, Hula is written in C and includes a dedicated web server. This means:

• While this is a great approach in terms of shear performance, I can crank out feature-wise equivalent amount of PHP code as perhaps a team of 3-6 C programmers, not to mention I have tens of thousands of lines of IlohaMail v0.x code that I can reuse.
• Compiling a dedicated web server isn't going to be an option for a great number of users. Just about anyone with a web server or web hosting service can already run PHP, and IMail2 can take full advantage of that existing infrastructure.

Finally, an apparently crazy but actually very insightful comment on writing software, from JWZ:

"How will this software get my users laid" should be on the minds of anyone writing social software (and these days, almost all software is social software). "Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

So XMLHttpRequest is one of those gems of modern browser technologies that's received attention recently (mostly thanks to Google Suggest), and it's been one of those things that make you go "Wow, that's so cool... but what am I going to use it for?"

Well, today, I found an excellent use for it in OpenHive. Start typing an author's last name or words from a book title, and watch as the list of candidates update in real time. The book title search replaces spaces with a wild card, so you can get to a specific entry very very quickly (for example, try typing "art int mod"). (Results may vary depending on the speed of your internet connection and computer, but should work in Mozilla/Firefox, IE 6, and Safari).

The only real problem with this particular use of XMLHttpRequest is that it hammers the server with requests basically as quickly as the user can type. So unless usage is low or you have insane computing resources (like Google), it's not quite practical. On the other hand, I'd say a site the scale of Amazon has no excuse not to implement something like this...

After several months of outage, BlogMatcher is back up. Apart from some minor internal cleanups, and UI tweaks, everything's more or less the way it was before. The biggest difference is that the indexer runs once an hour now, but only fetches the last 5 minutes' worth of data from Weblogs.com's shortChanges list.

In case anyone's interested, here's a rundown of what happened.
Show Rest of Post

We're almost exactly a week into 2005, and IlohaMail's off to a very good start.

• I now have an official Release Technician, who's going to do releases of the latest Devel branch code for me. It's the first time I got someone else to commit to a "position" in the project (other than as translator or packager).
• Two ISPs, Lycos-Europe and Kagoya have informed me about plans to re-distribute IlohaMail. Lycos has about 3 million customers, and Kagoya supposedly operates over a thousand servers (so probably a few thousand sites including hosted users). (See official news release.)
• I'm getting a lot of patches from users. One guy sent in 5 patches, and I got so overwhelmed I haven't processed them yet...
• IlohaMail 0.9 simply kicks ass. I think just about everything people have asked for is or will be there (except POP folders), and it'll be about 4 times faster to boot.

The one downside of an insanely stable OS is that... well, sometimes you get carried away.