I have been using Mozilla 1.4 for the past two weeks and have been very happy with the spam filtering capabilities. I don't really get a lot of spam, maybe three to five pieces a day, but it came with good initial filters and has learned pretty quickly. When I first started up and had it scan my Inbox, which was clean of spam, it marked an entire thread on [xml-dev] as junk.

Mike Lea aka mazeone on #joiito took his own life on Friday.

We came, we saw, we did, we got spanked, we did it right. Last week Mark Pilgrim and I released an implementation of the AtomAPI, both a client and a server. That implementation included a new authorization scheme that we came up with. Now we would have liked to used HTTP Digest authentication, and the AtomAPI should support Digest authentication, but for many users setting up Digest just isn't possible.

Christopher worked hard all summer baby sitting his youngest brother, mowing the lawn and doing chores around the house, all with the aim of collecting enough money to buy an electric scooter. Well he finally saved enough and it arrived this week. The EcoScooter he bought is a neat little electric scooter that runs on 24 volt batteries, runs for about a half an hour on a full charge, goes about 15-18 miles an hour depending on rider weight, and is really fun to ride.

"Is the HTTP verb PUT under Apache safe or dangerous?" This is a question I come across often, and have now run into it twice in the work on Atom. So is it safe? The answer is maybe. Continue reading The HTTP verb PUT under Apache: Safe or Dangerous? I've tried to post a comment via commentAPI , as it is specified in the RSS. But no luck ; getting HTTP/1.

"Is the HTTP verb PUT under Apache safe or dangerous?" This is a question I come across often, and have now run into it twice in the work on Atom. So is it safe? The answer is maybe. Here are two such examples: Using DELETE and PUT may be the "right thing to do" in an ideal world, but the fact of the matter is that a lot -- if not the vast majority -- of webservers do not allow these operations.

A real live working implementation of the AtomAPI has been posted. Mark has all the details. This is an implementation in two parts. The first is a server-side CGI script that Mark wrote in Python that hooks into a Movable Type installation. Yes, it's true, this is an AtomAPI implementation for Movable Type. The second part of the implementation is a client side GUI written in Python that allows you to create, modify and delete entries.

The tools may or may not save you: The tools will save you: The google calculator is amazing. For example, the total amount of energy released if the earth was turned into energy. Google is a tool. It saves me every day. The tools will save you: Nutch, an open source search engine project that has Mitch Kapor and Tim O'Reilly on the advisory board [via Joi Ito]. Open source is a tool.

pixelcharmer has a nice intro to using faceted classification with MovableType. A worthwhile read in itself it also contains pointers to other web resources on faceted classification: A Simplified Model for Facet Analysis Ranganathan for IAs IAWiki: Faceted Classification

I repeat, the AtomAPI is not a Web Service. At least as the term Web Service is defined by the W3C Web Services Architecture Working Group. Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

It's been a while since Google released it's SOAP based API and all ensuing discussion. I only recently have had a chance to play with the API and it does raise a question. Paul Prescod covered what the API would have looked like if it were formulated under REST, but his formulation does have a major weakness, in that it encodes the Google Key into the URI. The problem is that the URI may show up in referrer logs and thus increasing your chance of getting your key stolen.

Rev 07 – 6Aug2003 Latest version of the AtomAPI draft RFC is now available. Differences from version 6 to 7: Removed the use of the RSD file for auto-discovery. Changed copyright until a final standards body is chosen. Changed query parameters for the search facet to all begin with atom- to avoid name collisions. Updated all the Entries to follow the 0.2 version.

MTS, my former employer, is being investigated by federal authorities who suspect that it illegally sold testing equipment for nuclear weapons research in India.

I have tried this link checking service from the W3C, just drop in a URL and will check all the URLs on the page, looking for dead links or malformed ones. Cool, but just one problem, it fails with a 404 on every single link on my site. I think it's a content negotiation thing but haven't had the time to download the source to try to fix it. Found via my referrer logs.

One of the key features of the AtomAPI is it's potential for extensibity. As an example of that kind of extensiblity here in an outline of one way the AtomAPI could be enhanced in a completely safe way by a vendor. The example I am going to use is that of moods. Moods are pretty particular to LiveJournal and are reflected in their current XML-RPC interface. A mood is just that, the mood of the writer at the time they wrote their entry.

It appears there are now two implementations of the AtomAPI. The first is blojsom: So I decided that since the race today was rather boring, I would sit down and do an implementation of the EchoAPI editing api.[- Mark ] The next is Danny Ayers who put together an implementation in a mornings work: I was curious to see just how simple the Atom API actually was to use, and so have written a totally minimal blogging system using it - three files, a morning's work.

Previously I talked about the six different places there are to store information in an HTTP transaction. This is slightly misleading. To review, the six places are: Request URI Request Headers Request Content Response Status Code Response Headers Response Content This is slightly misleading because the URI is listed as a single storage location. This isn't the best characterization, as it really contains two different sets of information: the path, and the query parameters.

Went to the Atom Dinner in SF last night. I am the guy on the right in this picture Joi took. Strange that the only picture of me there is one of me taking a picture, strange since I didn't bring a camera. This was the first time I met so many people face to face that I had previously only talked to before either via mail or irc. I was able to stick around and talk for about an hour before I had to leave to get to the airport, so it was a lot of fun even though I missed all the food.

Bill de hÓra points out one of my biggest annoyances with HTML, that it doesn't support a larger complement of HTTP verbs. He does have a different spin on it than I had previously thought of, that because it only supports GET and POST that HTML effectively subsets HTTP. So, HTML subsets HTTP. If any other technology did that, there'd be uproar. Yet I don't think the W3C Technical Architecture Group have even discussed this.

The URIs in the draft AtomAPI RFC are not normative, they are examples. The draft RFC isn't about specifying the form of the URLs that are to be used. Yes, there are guidelines you should follow when creating URIs, but those are just general guidelines. That is an important document and if you're creating server side software you should know it already. Updated: Now includes the template editing facet.