Re: [Pyblosxom-devel] Supporting comments, etc.

[Wari W. <wa...@ce...>]

* Blake Winton <bl...@ph...> [030207 01:11]:
> http://uche.ogbuji.net:8080/uche.ogbuji.net/tech/pubs/ might help.  or
> http://www.xml.com/pub/a/2002/11/13/py-xml.html or
> http://xml.coverpages.org/xmlPython.html

I'll try and give it a read, again :)

> But yeah, it's a little tricky.  I stick with the standard "print"
> statements, myself.  They seem to get the job done.

The only code I've seen creating a proper XML document with DOM is
http://markpasc.org/code/tbpy/ ,  even that looks a bit heavy for me to
process :)

> That's why I tend to use DOM-based parsers, such as:
> http://www-106.ibm.com/developerworks/xml/library/x-tipulldom.html
> 
> I agree that XML parsing isn't the easiest thing to do, but it might
> be worth learning, and there are a lot of resources out there.

Well I guess there's money to be made on this :) Everyone's talking
about how cool XML is. There also people who talks about how bad XML is,
so it's subjected to debate. You love it or hate it, but can't ignore
it.

> Oh, one final question, are we happy with the location and name of the
> storageApy.py file?  Shall I check it in, given that we can always
> edit it further?

I'd prefer storageapi.py to sit in it's own directory, and you can place
the drivers there, like preformatters, name it base or something, and
the drivers can subclass it from there.

> You either write converters, or get other people to write converters,
> or get so popular that everyone else writes to your standard.  I'm
> hoping for option 3, but would be happy with option 2, and would even
> go with option 1 without too much complaining.  ;)

Option 3 is possible if we could make something standalone out of our
comments stuff and you can then sell it as a different package with its
own SKU :) Option 2 and 1 will only come about if the feedback system is
a killer application and people are dying to work with it :)

> The format shouldn't be pyblosom specific, but pyblosxom will handle
> it, and it will (apparently) be driven by the pyblosxom developers.

Can be done.

> We could write code for the standard blosxom to support it, and then
> all the other blosxom clones would be forced to add support for it to
> keep up.

Yeah, embrace and extend :)

> > We just need a well documented XML format then, agreed?
> Agreed.  Are there any we can snarf on the weeb?  (I've just done a
> search and found the following:
> http://www.diaries.com/digiboy/stories/storyReader$41 Handles threads,
> doesn't handle trackback/pingback.

Should be easy to integrate pingbacks and trackbacks, I donno what
post-it is, so I don't care about that yet :) But do we need something
threaded? Blog users (your visitors) can get confused with this, I know
because I used to have a PostNuke blog, and regular blog readers keep
creating a child thread, realised what they've done, complain about it
in a new thread, and the next comment becomes a child thread again,
complain..... rinse lather and repeat :)

People who visited slashdot or kuro5hin would have no problems with
threads, me too, I love geeky threads, but the world is not ready for
it.

Could be a feature that you can turn on and off though. But to enable
threading, do you need to change storageAPI?

-- 
Regards: Wari Wahab
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/