Report from last week's Hackathon

[Tim Bray <Tim.Bray@xxxxxxx>]

I'd sent an initial draft to Paul & Sam, but then forgot to follow up.  
These are notes that represent my personal take-aways and are obviously 
not binding on anybody.
====================================================================

1. We need another face-to-face at which some of the big implementors 
are present.  This should be an interopathon, obviously with open 
attendance, but focused on those who are going to implement the Atom 
protocol.  We envision January in California.  Whether or not this is 
an "official interim meeting" of the Atom WG is an open question, but 
we should get together.

2. We contemplate the idea of producing two drafts to cover the Atom 
Publishing Protocol.  The first, "Atom Publishing Protocol Basic" would 
cover introspection, collections, and entry creation/update/deletion; 
the second, "Atom Publishing Protocol Administration" would cover 
category and user management.  The idea is that a minimal client that 
doesn't want to manage a weblog, just to publish, could implement only 
Basic.  Maybe WebDAV is just the ticket for Administration.

3. We considered creating another XML namespace for APP XML markup (say 
"pub:") and inventing a <pub:control> element which could be included 
in an entry that's being POSTed or PUT, to contain stuff like 
trackbacks and comments and draft/published.  The idea is that it would 
be consumeed by the publishing system and not go into the feed.  This 
would be a good place for blogging-system vendors to put proprietary 
magic.  However, we would predefine some commonly-used controls per 
Brent Simmons' recent postings.  Thus my PacePubControl.

4. We sketched out syntax (with rough Paces) for the introspection file 
and the collections.  I started implementing the collections on 
'ongoing'.

5. There are several different types of collections: entries, non-entry 
resources (e.g. pictures), categories, users, templates.  We suggest a 
PaceFieldingLinks style setup for collection types with these 
well-known values, but people can have other types identified by 
arbitrary URI.

6. We have two alternate views of how a client could traverse a 
collection.  One (for which there's a Pace already) is ultra-simple, 
you just get a list of items, plus a "Next" pointer to get the next 
chunk.  It would be nice to have the total size of the collection as an 
attribute on the root so you know how far you have to go.  Alternately, 
you could have a setup where the top-level of the collection presents 
as a bunch of folders that you can traverse to, this enables 
random-access.  Bray leans to the simplest one, Sayre to the folder 
approach, he'll write a Pace.  Everyone agrees both will work.

7. Joe Gregorio gave a very well-received presentation on the Atom 
Publishing Protocol, he's going to clean up the slides and publish them 
[he did] and I think they'll be a valuable community resource.

8. We had some good argument about must-understand and I browbeat Joe 
about how inexpensive it was and how it might be useful, but he keeps 
saying "nobody has ever needed it so far." I still like the idea but 
suspect it's a lost cause.

 -Tim