Re: Thoughts on comments package

I really wasn't trying to imply that there were any specific feature

limitations in Pybloxsxom or to be overly critical of the existing 
codebase or to suggest that additional features can't be added to 
Pyblosxom. What I was trying to point out is that it seems there isn't a 
clear architectural pattern or established design practice for extending 
new functions like xmlrpc and feedbacks/comments to the app - and that 
if this trend continues over a longer period of time it could result in 
a pretty fragile codebase as backwards compatibility in managing all 
sorts of different hooks, scripts, hacks etc becomes really cumbersome.

--L
P.S. Also, I'm pretty willing and happy to dive in and help so please 
don't take all this as a "Why aren't you writing this already..." bit of 
whining ;)

will guaraldi wrote:

>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