The Habari developers have done a great job getting AtomPub implemented early on. The AtomPub implementation is now error free, according to the APE, but there are still warnings and it is still partially incomplete. As I see things, these are the outstanding issues that I know about, in no particular order. Each of these should probably be entered as a separate issue in the tracker. As I'm not super familiar with the spec, I've probably missed bits that Habari doesn't support. If any of this is wrong, or it's incomplete, or you think my solution is off, please let me know. [I've posted a similar message to habari-dev.]

Atom and AtomPub share a URL

While this works okay, because Habari uses the presence of authentication details to tell the difference between a request for a feed and a request for an AtomPub service document, it relies on the client sending a correct username and password with the initial request. If the client wants a service document and they don't send authentication, they'll get a feed instead of a 401 authentication challenge.
Solution: Provide a separate URL for the service document, probably /atom/service.

PHP as a CGI

When PHP is running as a CGI the HTTP Authorization header is not passed on to the script. Currently this means that authorisation will fail.
Solution: There is a simply (but ugly) workaround that uses mod_rewrite to write variables that the script can read. I have a patch ready for this, but haven't submitted it yet.

Support WSSE authentication

Habari currently supports only HTTP Basic Authentication. Some clients and devices only implement WSSE Authentication, such as the Nokia N73.
Solution: As a proof of concept in the past, I implemented WSSE in WordPress. One slight catch, and the reason it didn't work in WordPress, is that WSSE requires plain text passwords to be retrievable on the server. Are they available in Habari? If so, it should be trivial for me to write a patch.

AtomPub categories support

Atom entries can contain category elements. While Habari doesn't support categories, it does support tags, so categories supplied in an Atom entry should be written as tags on the post.
Solution: I've submitted a patch to do this.

AtomPub draft support

Habari does not currently support the AtomPub protocol provision for a client to send a request for an Atom entry to be considered a draft.
Solution: Detect the app:control element in Atom entries and honour the app:draft setting, where a value of 'yes' means the entry is a draft.

Atom media collection support

Habari does not currently support the upload of media collections.
Solution: This is contingent upon Habari implementing file uploads, and will be slightly more complex than publishing of simple Atom entries because there's a level of indirection between uploaded resources and their Atom entries.

AtomPub summary support

I'm not sure I've got a handle on this one completely. In the section entitled Media Link Entries, the AtomPub spec says, "[RFC4287] specifies that Atom Entries MUST contain an atom:summary element" but the Atom spec clearly says in both the (normative) text and (non-normative) RelaxNG fragments that atom:summary is optional. The Atom spec says, "It is advisable that each atom:entry element contain ... a non-empty atom:summary element when the entry contains no atom:content element." So, given an uploaded media entry, Habari may create a summary element for the media link entry associated with the media entry.
Solution: I don't really see any way of producing a summary automatically. I think the only thing we can do is to support summary elements provided by the client. As file uploads has not yet been implemented, it's trivial to add a summary column when it is.

Support foreign markup delivered by AtomPub

I'm a bit hazy on this one too. The Ape produces a warning when Habari drops a subject element that is a child of the entry element. The relevant section seems to be section 6 of the Atom spec, but it doesn't specifically say that foreign markup should be preserved. Section 6.2 of the AtomPub spec says, "Unrecognized markup in an Atom Publishing Protocol document is considered "foreign markup" [...] Clients SHOULD preserve foreign markup when transmitting such documents." While this isn't talking about servers, it implies foreign markup in legal locations should be preserved. I might be missing a reference here, but it seems to me the spec isn't clear on this point.
Solution: Explore the issue more.

Decouple app:edited and atom:updated

Atom entries can have a client provided atom:updated element. The purpose of this element is to signify that a significant change has been made to the entry. AtomPub provides the app:edited element, which is a server provided timestamp representing the last time that the entry was changed in any way. An AtomPub server can override the atom:updated value and use its own, which Habari currently does. Habari's Post class's updated column is written on all edits and is used to fill app:edited elements.

Solution: Create an edited column for the Post class, and use this to populate app:edited, and use the client provided atom:updated value (or a timestamp if it isn't provided) to fill the updated column. This would have the side effect that with a small UI change in admin, users could mark things as minor edits, such as fixing typos or adding tags. However, changing Post would also have far-reaching consequences. We could also sort the Atom feed by atom:updated, as this makes semantic sense and order is not mandated in the Atom spec, and still have AtomPub sending in app:edited order.

get_collection and get_entry violate DRY

Solution: Refactor the code.

PHP's errors have always struck me as being particularly impenetrable. There doesn't seem to be any explanation of the errors on the PHP site either. What the hell does Parse error: syntax error, unexpected ';', expecting T_FUNCTION in blah.php on line 145 mean? Well, the most likely explanation for that error is that you forgot the close brace on a class, so you have a function close brace immediately followed by ?>.

After their successful work on HTML5, CSS5, XML5, SVG5, and Web5, the WHATWG has announced that it has started work on a new version of the Bible, to be called "Bible5".

• FW: WHATWG to start work on "Bible5" from Michael Penman on 2007-06-21 (www-html@w3.org from June 2007)

Grrr. I mentioned before that hpricot downcases element names when parsing HTML, but it does when parsing XML as well. It doesn't claim to be a conforming parser, but it makes it a little less useful.

There's quite a difference between the terms of use of Google's and Yahoo!'s search APIs. While both say you're not allowed to do anything illegal or mission critical (I especially like Yahoo! saying you can't rely on the API if you're operating nuclear facilities), they differ in terms of what you're allowed to do with the results.

Google spends a lot of time saying what you're not allowed to do once you get results (you can only retrieve a small number of results (8 at the moment), you can't use them as the main content on your site, you can't modify them, you can't use a robot or spider to retrieve results). Possibly fair and reasonable, though, for my current (non-commercial, research) project, 8 results won't do and I want to break all those rules.

Yahoo! on the other hand, says absolutely nothing on the subject of what you can't do with the results. All they say is don't whack the server too much.

I previously dismissed PHP's alternative syntax for control structures, but after spending some time working on themes for WordPress and Habari, I've come to realise that it's actually very useful from a readability point of view. The point is that if you have a mix of code and HTML, as themes do, then it can be very difficult to work out what control structure that lone dangling close brace is actually closing. By spelling it out with a endif, endwhile or endforeach the code is made just a little bit clearer.

So, for templating, okay, I'll accept it. For other code, it's still at terrible idea.

• Write a mini AtomPub desktop client with a Shoes frontend
• Write a bibliographic tool (distributed?)
• Complete the AtomPub implementation in Habari (media and comments collections, content types, categories (tags), summary)
• Implement a templated workflow system
• Migrate to Habari
• ... um, finish my Phd, I guess

work out the non-technical threats to a project, then assign people to work on those threats. They're just as important as the technical issues/threats.

• the 200ok weblog

[Making OSS UIs work]

Do

1. Get a Benevolent Dictator
2. Make the Program Usable In Its Default State
3. Design Around Tasks
4. Write a Plug-In Architecture
5. User Testing, User Testing, User Testing!!

Do Not

1. Develop Without A Vision
2. Join the Clone Wars
3. Leave the UI Design Up To The End User
4. Make the Interface a Thin Veneer over the Underlying Implementation
5. Treat UI Design as Babysitting Idiots

• Humanized > Weblog: Ten Ways to Make More Humane Open Source Software

I've been playing around with Habari, and so far I've tested the install on three different machines. One of Habari's requirements is Apache's mod_rewrite, which allows URLs from a client to be rewritten on the server. This means that a browser can request a pretty URL, such as http://www.example.com/habari/really-interesting-post and it will be redirected on the server to a script that returns the post with the slug really-interesting-post. Mark Jaquith has written a good article about this in relation to WordPress.

When mod_rewrite isn't working, Habari will give you the following error message during installation (Habari is under pretty intense development at the moment, so this message may change):

AJAX Error

You might want to make sure mod_rewrite is enabled and that AllowOverride is at least set to FileInfo for the directory where .htaccess resides.

Server Response

404 Not Found Not Found The requested URL /habari/htdocs/ajax/checkmysqlcredentials was not found on this server.

The installer made a request to ajax/checkmysqlcredentials under the Habari installation. That file doesn't exist, but as I said above, to keep URLs consistent Habari maps pretty URLs to their real location using modrewrite. In this case, modrewrite isn't working, so an error is returned.

Now, modrewrite is very widely available, but isn't compiled into Apache by default. It's unlikely you'll get this error if you're using a hosted service, but you might if you've installed Apache yourself. First, you have to make sure that modrewrite is enabled. There are other configurations that will work, but if you compile Apache with ./configure --enable-module=rewrite --enable-shared=rewrite mod_rewrite will be installed.

So what's this about .htaccess? In its root directory Habari uses an .htaccess file, which is an Apache configuration file, to set up the rewriting rules. The default installation of Apache doesn't allow per directory configuration files, so if mod_rewrite is working it's likely that Habari can't rewrite the URL because it can't use the .htaccess file.

AllowOverride is an Apache configuration directive used in the main configuration file, conf/httpd.conf in your Apache installation, that tells Apache what sort of commands are allowed to be used in an .htaccess file. Apache needs to be told that it's okay to use an .htaccess file in the directory where Habari is installed. Your httpd.conf will contain something like the following:

<Directory "/usr/local/apache2/htdocs"="">
    Options Indexes FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

The Directory container specifies a directory where these directives apply. This is for the DocumentRoot, and also applies to its descendents. As AllowOverride None is set in DocumentRoot, no .htaccess files will be read in the Web directory tree. To fix this we either change the directive to AllowOverride FileInfo in the DocumentRoot or we can create another Directory container specifically for our Habari installation and set AllowOverride there.

Don't forget to restart Apache!

If you're interested in learning more, Sitepoint has an introduction to modrewrite rules, including a simple test to see if modrewrite is working.

[Update: mod_rewrite isn't included in Apache by default. I've corrected the error and expanded.]