From: Gavin C. <ga...@op...> - 2011-04-05 13:51:37
|
On Tue, Apr 05, 2011 at 12:07:02PM +0200, Axel Beckert wrote: >On Tue, Apr 05, 2011 at 10:08:19AM +0100, Gavin Carr wrote: >> >> Blosxom 2 as CGI does not run very fast with many plugins. >> >> And is missing mod_perl and fastCGI support and some API. >> > >> >I'd be happy to see a a working Blosxom within mod_perl (preferably) >> >or FastCGI. I though don't see currently how we could keep Blosxom's >> >elegant design while moving to some persistent process model. So if >> >anyone else find's a way... :-) >> >> FWIW, I'm working on a blosxom-3-like-thing at the moment, but it's a >> complete rewrite, rather than a fork. It's also static-only, rather than >> mixed static/dynamic. > >Well, the existing blosxom3 had the focus on being able to serve >dynamic content while having a persistent process. So I'd rather not >call anything doing static-only stuff "blosxom-3-like". > >I guess you meant a blosxom successor in general with that. Yeah, I just meant an updated blosxom in general. >Anyway, despite I'd be happyu to see blosxom working with mod_perl or >FastCGI, I still prefer static generation. Unfortunately many blosxom >plugins (my tagging plugin included, unfortunately) do not support >static generation. > >> And it's not quite as minimalist e.g. the core uses modules rather >> than a single file, and makes use of a few CPAN modules. > >Which doesn't need to be a bad thing nowadays. > >> It keeps text-based posts, hooks and plugins, flavours and themes, and >> generally has a pretty similar structure to blosxom. And so far it adds >> config files and built-in pagination to the core. > >Sounds neat. Any backwards-compatibility to blosxom flavours or plugins? No drop-in backwards compatibility. Theme-style flavours should be trivially portable though. Plugins should also be portable fairly easily, but will require code changes, as the internal and hook interfaces are all different (no globals, different hook function signatures, etc.) -G |