Re: Thoughts on comments package
will guaraldi <[email protected]>
| Newsgroups | gmane.comp.web.pyblosxom.user |
|---|---|
| Message-ID | <[email protected]> |
Whining is good. Feedback at this stage in Pyblosxom's life is really important since the API is not frozen and likely to keep changing until 1.0 at which point it will be frozen (or at least, this is my understanding). The more usage we see, the more of a general understanding we'll have of the problems and their solutions in the Pyblosxom framework. So I'm cool with that. The "problem" here is two-fold. First, we're on our second wind in development and development of the core is happening at a quicker pace than fixing up of the plugins to match the changes in the core. That's somewhat to be expected at this stage in 0.9 development. The second problem is that I've been making architecture changes without really publicly explaining the algorithmic nuances of the changes--namely what they now enable you to do. So it's all good. What you said was based upon everything you'd seen so far and a perfectly valid viewpoint. My reply was less to tell you that you're wrong and more to state that we can (as far as I know) already do those things, but that I'm in the process of playing catch-up with documentation. Give me a few days to sort out xmlrpc (assuming there are things to sort out) and I'll probably publish a blog entry or something to that effect that walks through how best to implement data submission. Hope that clears stuff up. :) /will On Thu, 12 Feb 2004, Lance Weber wrote: > > 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 ;) ------------------------------------------------------- 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