Re: Thoughts on comments package

On Feb 12, 2004, at 2:01 PM, will guaraldi wrote:

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

I'm fine with the whining too.   The comments system uncovered a lot of 
issues
with pyblosxom's architecture the first time around, so it's not 
surprising that
there are still issues left be dealt with.

Remember that the initial pyblosxom was basically a straight port of 
the Perl
blosxom code, which at the time did not have plugins, etc.  In some 
ways, we
are still using that model, and that's why we have all these CGI's -- 
believe me,
I'd love to get rid of them.

To do things like trackback, pingback, comments, blogger, metaweblog, 
and Atom,
I agree that we should move to a model where there are entry points in 
the core
(actually probably methods on Pyblosxom) the can be called to implement 
functionality
like creating and deleting entries and so forth.  To do this in a 
completely general
way will probably mean pushing some functionality all the way into 
classes like
FileEntry so that we could do DBEntry at some later date.

As far as changing URL patterns goes, that's another thing that I'd 
like to change/fix,
but we've been pretty much adhering to the blosxom rules for URI's.   
There was a long
series of posts a while back on organizing URI's, and in an ideal 
world, I'd like
pyblosxom to be able to do those formats as well.

I just wasn't sure how radical we wanted to be -- I'd actually like to 
tear a bunch
of stuff apart and do it over, but I didn't think that was on the 
table, and I'm not
sure it should be until 2.0.

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

As you do this, keep in mind that we'll need a way to produce error 
replies as well.

Another thing about the current architecture is that it makes it very 
difficult for
me to provide comment preview, which is something that people really 
would like to have.
To do preview, people submit the form, but we don't have a way of 
injecting that back into
pyblosxom because it's a cgi script -- I didn't write the comment data 
to disk, because it
was a preview, but then the pyblosxom script exits and the data was 
lost.  I know how to
fix this problem in the Java servlet environment -- I'd just stick the 
data in the session,
but in the CGI environment, I haven't thought of a clean way to solve 
this problem.

> 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
> _______________________________________________
> pyblosxom-users mailing list
> pyblosxom-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-users
>
----
Ted Leung                          Blog: http://www.sauria.com/blog
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42



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