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.
Full version - 0 Comments