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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.