I am thinking about this right now, as of two days ago in fact, and
its like a watershed moment as I peeked at Blogofile, was amazed it
was picked up by Doug, and is full steam ahead!
In fact, I found absolutely zero mentions of this notion anywhere,
googling today. Until this, and its from my favorite blog engine, we
think alike.
The front end i have in mind is probably broader in scope than
Blogofile itself. It's basically an end-to-end solution you could
give to like, your dad or your uncle, and they can "build their site"
in a way that wont annoy the crap out of you when they ask you to do
something with it.
thoughts I have in mind for this "static CMS frontend" are:
1. is it a desktop application, or a local server that your browser
hits ? The former would be nicer but way more work - its really more
like, hey let's do a web startup, have a free download with options
for the "deluxe" version, etc. So probably not.
So as you mentioned, a dynamic web application (of course I'd write it
with Pyramid) would be the way to do that - however I'd want this web
app to be equally at home running on your local machine as it would be
on a remote host. I think there is definitely a model for the
"management" software to all run locally, pushing out to repositories
that can be shared (that is, let the security just be standard git +
shared static host security). When all you have to host on the
internet is git + static site, its much easier and more secure rather
than having a custom written dynamic web app with passwords and
security and stuff running on a hackable server.
2. Built in support for versioning. Some modular approach would
link it to mercurial or git. Git would be nicer because, its git and
everyone's apeshit over git, mercurial would be nicer because its
Python and you can Python API right into it, and it has fewer pointy
edges.
3. but this is for your dad, he will never know how git works. So it
would really present a fluffy, puffy facade over the whole thing that
shows you just "your posts" and "versions" and "revert to old
version", etc. The git repo is obviously there for the tinkering,
of course.
4. the git repo can push out to various locations. keep it on your
harddrive, or add a "github provider" so it pushes out there, *or* I
have in mind maybe have it push to S3 too, though this would require
an S3 storage engine. I'm really into S3 for mom-and-pop websites
since its practically free. I don't know that my dad wants a github
account. I'm really impressed by S3 and other similar bucket-based
engines like Google Drive and DreamObjects (all of which Boto can talk
to).
5. publishing of course has lots of options too. Publishing can be
to: 1. a git repo somewhere that does the usual "build hook", 2. an
FTP host if you're on a godaddy type of situation, or 3. an S3 bucket,
which is where I host most static sites now.
6. mobile "post" hooks ? like an app, or an email hook ? fun.