Re: Thoughts on comments package

Um...  I'm pretty sure Pyblosxom actually does more than you think it
does.  If you look at my registry plugin, it handles both viewing existing
registry entries as well as submitting new ones (which would fall under
your command idea).

I haven't looked at the comments work that Ted has done yet, so I can't
really speak for what he's built so far and how it's architected.  Also,
it should be noted that the original work on the comment stuff was done a
while ago--I've been making very undocumented changes to the architecture
to meet my selfish and diabolical needs for a while now--the effects and
nuances of which I don't think I've really communicated to the other
developers including Ted.  That's my fault.  Getting there....

Right now I'm in the process of testing the xmlrpc stuff and making sure
it works with the changes I've made.  It's ironic that I was also toying
around with re-writing the xmlrpclib that we have and changing it to be a
Pyblosxom plugin.  It's a mild restructuring of the xmlrpc stuff, but I
think it'd be a better fit with what we have.  And it, as you say, makes
configuration much easier in the long run.

Give me a few days to sort out the xmlrpc stuff and see if these theories
are true or not and I'll let you know what I discover.

/will


On Thu, 12 Feb 2004, Lance Weber wrote:
>
> After looking at the comments package (its more than just a plugin!), I
> can see why it has a reputation for difficult installs. Clearly, adding
> additional functionality like this is an edge case with pyblosxom -
> figuring out why is good food for thought.
>
> In the long run, I don't think that extending pyblosxom by adding more
> and more cgi scripts is the right "best practice" for this type of
> application from a dev/test standpoint. Additionally, as an end user, I
> want as little web server configuration on my plate as possible. _and_ I
> want the ability to easily use aliasing/rewriting to control how my
> url's look. The pyblosxom.cgi should be able to do what little is
> needed/required before passing on the data to the pyblosxom engine, no
> matter what functionality is being invoked.
>
> This also requires that the pyblosxom engine be "command" driven, and
> that plugins should have the ability to implement a command method that
> can listen and respond to specific commands. The current engine
> implements an implied "view" command. An xmlrpc plugin might implement
> several new commands that conform to the various xmlrpc blogging
> standards. A feedbacks plugin would support the various
> pingback/trackback/comments commands. As Atom continues to cook along, I
> could definitely see an atom plugin implementing atom commands.
>
> So, I'd suggest that pyblosxom support a new url pattern along the lines
> of a straightforward "$base_url/<command>/<parm>" structure. In order to
> maintain backwards compatibility, view would be the default command, so
> that a url missing the <command> structure would have the <parm> section
> sent to the default view code. However, this opens the possibility for
> naming collisions: does "$base_url/xmlrpc/test" refer to an xmlrpc
> command or my xmprpc blog topic? I'd suggest a naming convention that
> requires commands to begin with an underscore so that
> "$base_url/_xmlrpc/test" refers to a command while
> "$base_url/xmlrpc/test" refers to a topic. This would also make the
> command parse a lot easier/faster too.
>
> It looks (to my inexperienced eye) that Pyblosxom.run() could handle
> this pretty easily, especially given its usage of the callback patterns
> already.
>
> Thoughts? Thanks for being patient with me as I get up to speed...
>
> --L


-------------------------------------------------------
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