Re: Thoughts on comments package

I think handling the handler thing is really trivial and works out of the
box right now with the existing Pyblosxom stuff.  I'm not sure I agree
with Wari that Pyblosxom is just a viewing application right now.  That
was definitely true before, but isn't true now.

Anyhow, I don't think anyone needs to add anything to the existing
framework.

For example, take the existing xmlrpc stuff.  The xmlrpc.cgi script sets
up a Pyblosxom object, initializes its own config, initializes its own
plugins (I don't recall why we decided to separate the xmlrpc plugins from
the "regular" ones--I'm not sure that's needed), and then handles the
request which is in the data portion of the HTTP POST.

All of that can be done with the existing Pyblosxom framework without any
problems (you'd implement a renderer for the xmlrpc output).  We could
make it more efficient (Ted mentioned that it's kind of silly to have a
trackback error go all the way through the Pyblosxom pipeline) by
implementing a handle callback which would get called before the pathinfo
callback.  The handle callback would call all the functions registered and
ask them if they want to handle the request (i.e.  processing the request
all the way through producing output).  If they handle it, they return 1
and we're done.  We move the existing blosxom processing to a
handleBlosxomProcessing callback.

My first blush examination is that this is easy to implement.  I was
planning on putting this together and taking it through its paces to see
how easy it is to implement.


The thing I dislike about Pyblosxom right now is that for a user to add a
plugin, there's 1) no standard way to let the user know what configuration
changes they need to make, and 2) no good way of letting the user know
that the plugin is misconfigured.

I think that problem needs to get solved by 1.0--even if it's a business
process change as opposed to a code change.

/will


On Fri, 13 Feb 2004, Lance Weber wrote:
>
> I don't think anyone I've seen on the list so far wants pyblosxom to
> turn into YAMP (Yet Another Monolithic Project) - heck, I was just
> ranting about java monoliths yesterday in my blog ;)
>
> But, having said that, the question really comes down to how the end
> users view the tool. If you want your blog/pyblosxom to be the core
> engine of your site, then you're going to want tightly integrated full
> featured plugins like xmlrpc, the comments suite, etc. On the other
> hand, if you view your blog as just one component of your site that
> needs to interact with many other components (you could have a wiki, rss
> newsreader, blog, standalone trackback etc), then you may be looking at
> lighterweight plugins that glue external components to your blog, like a
> tbpy plugin to integrate trackbacks.
>
> Of course, it's really up to the project developers to decide if they
> want to support full featured plugins as they require a much deeper
> exposure to the inner workings of the system. If you do, then you are
> going to have to live with people using the codebase in ways for which
> it was never intended and encountering all kinds of funky consequences.
>
> On the other hand, making a conscious decision to only support a very
> narrow glue oriented API results in a much more manageable but limited
> code base, but at the cost of potentially shutting out those users
> looking for a fully featured core website application.
>
> Frankly, if I had a vote I'd urge towards a minimal api that focuses on
> loosely coupled operations. But, I also just finished reading ESR's "The
> Art of Unix Programming" (highly recommended!) and I may have a
> lingering bias in that regards...


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click