Where Everybody's Crazy

Simon Wistow is right. I want to amplify and expand on some of what he said there.

• All web frameworks do exactly the same thing, in the same way that most programming languages are, as Dan says, just Algol with funny hats. So stress the distinctives: is yours supremely easy to set up? Does it allow you to admin it over the web nicely? (Nice one, Django)

• Pluggability is not necessarily a good distinctive to stress. Actually, the choice of model/view is largely irrelevant to gaining traction, as Rails - and, dare I say it, ASP has shown. I don't hear ASP folks crying out for twenty different ways to access the same data just because they can.

  When I was designing Maypole I tried to make it easy for people to implement other model and view classes. It is a matter of debate as to how well that design panned out, but, after long talks with Tony, I changed the emphasis on why I was doing this. As Simon points out, most people don't want a piece of software that can do a bazillion things; they want one which does do one thing, and one thing well. The Unix philosophy is there for a reason.

  So for me the support of alternate model and view classes was not primarily to allow Maypole to be all-things-to-all-people, (although it is a very nice side-effect) but as a proof of concept to ensure that I've got all the concerns properly separated at the right layers of abstraction. If Maypole is "too" tied to CDBI and TT, that's a feature, not a bug.

• Number and scope of plugins don't matter, for the same reason. Applications (in the sense of "what is applied") matters. I don't care if you have 40 different ways of doing authentication if I'm never going to use 39 of them.

• Develop for the 80 percent solution. I tried to do this with - and now I'm thinking about authentication plugins - the UserSessionCookie authentication module for Maypole. 80% of the time, it's exactly what you want. 10% of the time you have to subclass it. 10% of the time you need to write your own. Don't make people choose between a myriad of options for the most common case.

• I'm going to start working on a way to make setting up Maypole apps much easier; basically one command-line call should write you the code to get CRUD working with factory templates on an existing database and, what the hell, dump a new Apache config file out to /etc/apache/conf.d/ and restart Apache. Because 80% of the time, that's exactly what you want, and its ease of use would be a helpful distinctive for Maypole.

• Yes, those default templates need redoing by someone who has a better sense of design than me.

• I will start thinking about very cool demonstration project ideas.

I think that's all for now.