Tim Bray: And by the way, as of the writing of this I’m not aware of any APP server implementations that get green check-marks all the way down the line from the Ape. You can run the APE against my apptestsite: http://bitworking.org/projects/apptestsite/app.cgi/service/;service_document No name or password are required. You will see that some things don't look quite right: 1. Content-type must be 'application/atomserv+xml', not 'application/atomsvc+xml' That's not true as of draft-14.

Elliotte Rusty Harold [via Brandon] : PUT remains one of the most confusing HTTP verbs because it is so frequently misdescribed, even by people who really do know better. The real lesson here is to check all my analogies with Elliotte first. The upside is that I can stop writing the disclaimers, which don't seem to get read anyways. He is of course right. All of the APP developers should take that lesson and do something about it in the APP specification.

Version 0.3.0 of the httplib2 Python library is now available. From the changelog: 0.3.0 Calling Http.request() with a relative URI, as opposed to an absolute URI, will now throw a specific exception. Http() now has an additional optional parameter for the socket timeout. Exceptions can now be forced into responses. That is, instead of throwing an exception, a good httlib2.Response object is returned that describes the error with an appropriate status code.

Elliotte Rusty Harold Apparently Google does not recognize XHTML, at least not when served as application/xhtml+xml. Try this search which should return exactly one hit pointing to an XHTML document. Notice that the file format is “unrecognized” and they offer to let you “View it as HTML”. Ouch. I appear to be suffering from the same fate. Oddly enough, Sam doesn't seem to have that problem. The difference between us may be in content negotiation.

Draft 14 of the Atom Publishing Protocol is now available.

One of the questions that has arisen several times recently is validation using REST. The scenario is that a client, a web page or some other agent, needs to do some quick validation for feedback to the user. For example, when entering a zipcode into a form we'd like to check that zipcode as it's entered and display some visual feedback when it's valid. Let's follow our REST recipe and see what we end up with: Find the nouns (resources).

The Critter Generator has been online for only five days and it's already been ported to PHP and incorporated into a product. w00t! I hadn't time to do this, but one thing that seems pretty obvious to me was that the critters can be whipped up entirely in DHTML. Consider this article on css sprites. Assume you've got a set of pngs with 8 variations of a feature in each png.

Alan Kay's 1997 OOPSLA Keynote. File under: REST

Guido van Rossum The plan is to write all applications in Python (except for the web browser), and a "view source" button should show the Python source for the currently running application. In the tradition of Smalltalk (Alan Kay is on the OLPC board, and has endorsed the project's use of Python) the user should be able to edit any part of a "live" aplication and see the effects of the change immediately in the application's behavior.

Michael Champion: I have to take issue with your point (quoting Joe Gregorio) to the effect that an enterprise developer with 300,000 users has reached the pinnacle of the profession while a Web developer with 300K users is ready to move out of the family garage. First, those 300K Web users probably are probably doing mostly read operations on public information. That wouldn’t be much of a challenge for even a novice enterprise developer either.

Inspired by Combinatorial Critters, and MonsterID, which allow you to create critters from combinations of parts, I just couldn't help but think, "That would be so much better as a web service", and thus the Critter Generator was born. Now, as you will soon realize, I am not much of an artist, so if you want to take a crack at creating monster parts I'd love to update the service with some real art, and if anyone sends in another 'set' of parts I'll update the service to allow selecting among the sets sent in.

Everyone seems to be playing the "how are we going to program for lots of cores" game since Intel announced their experimental 80 core processor. Maybe we can go forward by looking backward: StartServers 80 Seriously! I have seen quite a few "threads aren't so bad" and "Python's GIL will doom it" posts since that announcement. People seem to forget that threads are were created as shared-memory lightweight processes. Why not just use *real* processes and let the OS do its job?

Dan Bricklin points to a cool demo of embedding a YouTube video into a wikiCalc spreadsheet. Of course, in a show of self-referential-integrity, the demo is done as a screencast and is hosted on YouTube. Meanwhile I upgraded to the 1.0 release of wikiCalc and have my sparklines embedding down to a single line: B1=wkcHTML(wkctext("<img src='http://bitworking.org/projects/sparklines/spark.cgi?d=", wkcjoin(A2:A21), "'/>")) That requires the wkcJoin() function which I added to my install, but that doesn't detract from the fact that we're getting closer and closer to spreadsheets as mashup fabric.

I needed an army. The seventeen pencils previously attached to those erasers apparently didn't make the cut.

James Snell: IBM just filed a blanket IPR disclosure relating to the activity of the Atompub WG. The terms are Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers. Licensing declaration is limited solely to standards-track IETF documents. The other part I'd like to highlight is that this applies to both the syndication format and the protocol.

Matt Asay: Why? Because I don’t believe the Linux desktop will ever go mainstream in the “developed” nations of North America and Western Europe. We just have too much experience with Windows. The benefits of moving off Windows (or, in my case, the Mac) are outweighed by the costs. Not dollars-and-cents costs, but productivity costs. It’s not worth $400 to me to switch to an experience that doesn’t work nearly as well (especially since I can get my applications as open source, like OpenOffice, Handbrake, Adium, etc.

Dan Bricklin has a podcast interview with Ward Cunningham. Not many people talk about Forth these days, I mostly get blank stares when I mention it, but Ward talks about it in the same breath as Smalltalk. I frequently talk about using domain specific languages in development, and in a constrained environment such as embedded systems, building a DSL on a Forth interpreter is easy. I've implemented a Forth-like language in about 300 lines of C code.

Draft 13 of the Atom Publishing Protocol is now available. This drafts adds in the verbage that our Area Director Lisa Dusseault wanted added before she would let the specification progress to last call. In addition the specification now contains James' Atom Format media-type 'type' parameter specification. The document references have been updated to be more consistent, adding URLs to some, and shortening up some other anchors. Finally the RNC has been cleaned up.

Two brilliant quotes from Alan Kay in 2003: OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. And But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "

Steve Yegge has succeeded in generating a lot of traffic by obtusely trying to predict The Next Big Language. It's disappointing to see that most people have fallen for the trick, which was not to actually predict which language will be next, but to actually frame the debate: implying that there is always one big language winner. Let me be the first to call BS. Again. I guess for me the next big language will be the one integrating in an easy way parallelization.