BloggerCon Infrastructure session

I’m thinking about what sorts of folks could help make the BloggerCon Infrastructure session a big success. I think people who want to learn about the infrastructure will be there by default. The trick is to make sure there are knowledgeable people there to answer questions and keep the discussion going. Here is a list of profiles to help with figuring out who to reach out to:

A writer who is famously obsessive about tracking their rankings and inbound traffic. We would expect this person to be expert on how Blogdex compares to Daypop and Technorati. They may also be familiar with how desktop editors work.

A reader who has searched for, and maybe found, the “perfect” news aggregator. This person will have tried various aggregators and can talk about how centralized aggregators compare to desktop aggregators.

A lone developer who has used the infrastructure to build something totally different from what came before. Like the writer and reader, this person is a customer of the infrastructure. This person should be able to explain what “pings” are and explain basic distributed computing ideas to a non-technical audience.

An entrepreneur or other centralized service operator who has to worry about keeping servers alive and paying the bills.

These are just profiles, of course, many of which may live inside the same person. Also, we are not limited to having just one person per profile. The more the merrier! Can you suggest articulate people who meet these profiles and can be in New England on October 5?

Design proposal: External Authentication in Manila

Here is a short proposal for a Manila modification that allows authentication against either the local database or a single remote system.

1. On any page where a user is asked to create a new password (“New Site”, “Sign Up”), we instruct users that have an address ending in to leave the password fields blank. Users with emails in other domains should enter passwords as usual. We modify the input validation accordingly. With the exception of the blank passwords, user records are created in the object database at the same time and in the same way for all users.

2. On any page that validates a user’s password (“Login”), we check for an extension. If we find one, we validate against the school’s authenticator. If we find some other extension, we check the password in the usual way.

3. Upon successful authentication of an external user, we issue a dummy “native” password as David Carter-Tod describes at, so that mainResponder to use cookies in its usual way.


  • Local and externally authenticated users can be distinguished by looking at their email domains. Hence should be authenticated against the school’s authenticator and should be authenticated against the local database.
  • An externally authenticated user’s username is equal to the first part of their email address. So should be authenticated against the external system with username “student”.
  • We will not do anything fancy to synchronize profile information, such as the user’s name and address, against a central system. This information must be entered and managed in Manila for all users.


  • No new pages or changes to screen flow.
  • Small changes to existing pages.
  • (I think) No changes to Manila core.


  • How do we arrange things so that our modifications to member.login() appear in each new site when it is created?
  • What other pages will be affected by our change? E.g. “email my password”.

I see that two popular techie bloggers, Aaron and Mark, are letting us see the edits they’ve made to their posts.

Reading a few edit trails, it’s fascinating to see what they capture. Accountability and archivalness aside, I think edit trails could serve as a great tool for writing instruction. Most of us don’t get it right the first time. The magic is in the editing. Capturing and studying the edits of a great writer could teach us a lot.