RE: [Pyblosxom-devel] Lucene and comments

[Blake W. <bl...@ph...>]

> >#2.   For comments I have the following issues
> >We need a way to display a single article in a page, (so 
> >that we can put the comment form up).  This probably just
> >means invoking a different template for the single article
> >case.
> Yup.

Or a comments flavour, which is a different way of saying
the same thing, I guess.

> >handle post 
> Again, the need for your point #1. :) To make life simpler,
> I'm suggesting a comment.cgi type of program to handle
> comments.  We can make pyblosxom handle everything, but as
> feedback mechanism goes, you'll find trackback and pingback
> requiring xmlrpc mechanism to input feedback data.

But XML-RPC still works over HTTP, doesn't it?
I might look into this after we've got the chains set up.

> Then you'll need some management of feedback data, especially 
> deleting feedback spam if necessary (of course to know if
> you're spammed, to need to mail every feedbacks to the users).

This would be easy enough with human-readable comment files.
Other storage implementors would need to be more complicated.

> I'm not sure what Blake have in mind, he would also like
> pyblosxom to handle POST and GET requests too. XMLRPC uses
> POST too, incompatible with GET requests and cgi module won't
> handle it.

I just want PyBlosxom to support a couple of other ways of
adding comments.  Although, if we supported PUT, we could
add entries as well.  Version 2, perhaps.  ;)

> >We need a way to display the comment / trackback / pingback 
> >count (retreived from the storage api) in story.html (via a
> >variable) -- so every iteration through valid_list needs to
> >be able to talk to the storage api.  This seems like another
> >place for a callback chain.
> Counts can be done by the standard load() plugins, iterating 
> thru values of entryList at each call by using a standard
> incremental style of iteration. The plugin would call
> storageAPI to get relevant data of comment counts and what
> nots.

And the storageApi would cache various values if it was found
to be too slow.  (Getting the number of comments for a single
entry should be as simple as:
comments = storage.get( Storage.COMMENTS, entryId )
py['commentCount'] = len(comments)

> >I just wanted to get your thoughts on this before I plunge ahead.
> More things to consider, how do you tell pyblosxom that you want to 
> disable comments on a particular entry? Would some meta data like:
> '#comments 0' in an entry work in order to disable comments?

I'm not sure I like meta-data in comments.  I mean, it's a sexy
idea, and it gets a lot of stuff out of config.py that probably
shouldn't be in it.  I guess what I'm objecting to in this particular
instance is the syntax.  I've already put a python program listing
in my weblog, which contained lines starting with "# comment" (or
at least, it should have...) and to have those lines filtered out
would be a royal pain.

How do we feel about '<!-- pyblosxom-meta comments="0" -->'

> Also, what about making comments inactive for a particular entry
> as well? In my other blog I have to delete one entry because it
> recieved 100s of stupid comments and I can't disable it in MT
> (MT will fix that in 2.6)?

How does this differ from the above suggestion?

In either case, my recommendation is "Version 2!" Hey, MT didn't
get around to adding it until version 2.6, so the way I figure
it, we've got 2 whole versions to go before we need to have it
on the agenda.  :)

> Sorry if this mail sounds negative, I'm all for feedbacks, I want it 
> badly, but it does not seem to be an easy task with all these issue 
> lying around.

My take on it is that you should plunge ahead (using the work
that's already been done, of course.  Email me, and we can talk
about which pieces I can write for you).  Let's get something,
and then make it work better, instead of trying to solve all
our problems now, and never coming up with anything.  As the
IETF motto says, "Rough concensus and running code."  I think
we've got the rough concensus, let's get the running code.

Later,
Blake.