pyblosxom-devel — Development Mailing List for pyblosxom

[Pyblosxom-devel] config.py changes

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

As discuss earlier, the concensus was that there will be no windows INI 
type config anymore, and if possible to use default values.

I've checked in the changes, for those of you who used config.py in your 
cvs for your configuration, a cvs update could result in a conflict, so 
save a backup of your config, remove config.py, do a cvs update, and 
that should work.

cvs conflicts do place nasty <<<<<<<<< and >>>>>>>>>> lines.

Re: [Pyblosxom-devel] Entryparsers, what are they?

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

Wari Wahab wrote:

> I've checked in some code today, basically infrastucture stuff. But what
> the heck is infrastructure and what am I actually doing. I've got to
> answer this question first I guess.

I do wish that you guys would give some feedback concerning this before 
I loose my morale, oh well never mind? Does silence means I should go 
ahead and do it?

> 2. Multiple entry file types

Any way, to boost my morale back up again, I saw this message on the 
blosxom mailing list - http://groups.yahoo.com/group/blosxom/message/567

Which mentions:
----------------------------------------------
I read about another piece of blogging software that had some very
interesting differences - the feature that I took notice of was the
ability to parse files of different file formats and render them in
HTML.

So I got to thinking: After the plug-ins support comes, it would be
neat to write plug-ins that would, upon encountering certain file
extensions, process the file a bit differently, possibly converting to
html in the process, and dumping the result to the page. For example,
a .csv file could be converted into a table automatically. This
obviously would be a cute first step... but then we could look at doing
rtf->html conversions, or .doc -> html conversions... much more useful,
don't you think?
-----------------------------------------------

Yes I'm proud that at certain features, we are the innovators :) And 
this was only after yesterday when I checked in entryparsers.. People 
are watching :)

Re: [Pyblosxom-devel] Entryparsers, what are they?

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

Wari Wahab wrote:

> I've checked in some code today, basically infrastucture stuff. But what
> the heck is infrastructure and what am I actually doing. I've got to
> answer this question first I guess.

I do wish that you guys would give some feedback concerning this before 
I loose my morale, oh well never mind? Does silence means I should go 
ahead and do it?

> 2. Multiple entry file types

Any way, to boost my morale back up again, I saw this message on the 
blosxom mailing list - http://groups.yahoo.com/group/blosxom/message/567

Which mentions:
----------------------------------------------
I read about another piece of blogging software that had some very
interesting differences - the feature that I took notice of was the
ability to parse files of different file formats and render them in
HTML.

So I got to thinking: After the plug-ins support comes, it would be
neat to write plug-ins that would, upon encountering certain file
extensions, process the file a bit differently, possibly converting to
html in the process, and dumping the result to the page. For example,
a .csv file could be converted into a table automatically. This
obviously would be a cute first step... but then we could look at doing
rtf->html conversions, or .doc -> html conversions... much more useful,
don't you think?
-----------------------------------------------

Yes I'm proud that at certain features, we are the innovators :) And 
this was only after yesterday when I checked in entryparsers.. People 
are watching :)

Re: [Pyblosxom-devel] next steps

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

will wrote:

>The coding conventions thing is irritating and coupled with rare
>commenting makes it difficult to figure out what's going on.  I have a
>standard that I use with Lyntin and now I'm using it with Stringbean as
>well.  It's adapted from Guido's style guide with some changes to make
>generating out of line API documentation more comprehensive.  I'd suggest
>that as a good first draft.  It involves indenting by two spaces, but we
>can go with whatever indentation method you guys want to use--I don't
>really care either way.  I care more about inconsistent case usage in
>variable names, vs class names, vs function names.
>  
>
Here's some coding conventions that Will mentioned, and I have it carved 
in stone (well not really) at 
http://wiki.subtlehints.net/moin/PyBlosxomHacking/CodingConventions 
shamelessly copied and ripped from the Lyntin Coding Style Guide. It is 
now the official bible (subjected to revisions :)

[Pyblosxom-devel] next steps

[will <wi...@bl...>]

Wow--I didn't mean to cause such a raucus or make anyone feel inadequate 
or anything.  I'm just concerned about the state of things and whether the 
development process you guys want to do matches something I can deal with.  
I have a couple other projects I work on and I can't spend a huge amount 
of time trying to figure out what happened day to day.  So I just don't 
have the time for projects that want to involve more of a chaotic 
development process.

So that's where I'm coming from.

Having said that, I'd like to clarify some things.  When I said that I'm
not down with "code first discuss later" I meant more along the lines of
"code first, commit to CVS, discuss later".  It's that middle step that I
find really difficult to work with.  I'm definitely into people doing the
analysis and research and trying out various ideas in code as we go
through figuring out exactly what we're doing.  If you feel the need to 
send diffs to the list, that's fine.  I think in most cases it's not 
something we need.  Bug fixes should be committed--just new development 
and changes to the core architecture that need to be ironed out before 
being committed because it affects everyone in different ways.

This doesn't need to apply to everything.  I think if someone was going to 
whip together a plugin for ... well, let's use my calendar plugin as an 
example.  It's a plugin and is additional functionality.  If someone 
wanted to whip together something like that which doesn't affect anyone 
adversely and then check it in, that's fine.  It's when we're all 
adjusting pieces of the core architecture and changing the way things 
operate and the default behavior that I really would want to measure twice 
and cut first, so to speak.

I definitely don't think we need a full specification process like Sun has 
with Java, either.  I just want a clear understand of what people are 
doing before they do it because then each of us can figure out how it 
affects us and what additional things could be involved.  We're not in a 
rush--we don't have a deadline to meet--so we can take our time and think 
things through as we go along.  We'll end up redoing things over and over 
again and the codebase will end up much easier to manage.

I'm not saying anything wildly exciting or new here.  I just figured it 
needs to be said by someone so we all know we're on the same page.

The coding conventions thing is irritating and coupled with rare
commenting makes it difficult to figure out what's going on.  I have a
standard that I use with Lyntin and now I'm using it with Stringbean as
well.  It's adapted from Guido's style guide with some changes to make
generating out of line API documentation more comprehensive.  I'd suggest
that as a good first draft.  It involves indenting by two spaces, but we
can go with whatever indentation method you guys want to use--I don't
really care either way.  I care more about inconsistent case usage in
variable names, vs class names, vs function names.

I forget what the other thing I whined about was.  Hmmm....  Probably 
wasn't wildly important.

I have to run, otherwise I'd do more work tonight.  I think what Ted (I 
wrote a post-it note reminding me that Ted likes to be called Ted and that 
Blake is subscribed to both lists and doesn't need repeats) did is fine 
for now.  I'll look more carefully at it and compare it to the other 
things we were discussing last week and augment what he's already written.  
I'll probably do that tomorrow or Wednesday.  Definitely don't worry about 
backing out the changes.

Even though I got all concerned, it's exciting to see such a flurry of
development happening on such a diverse set of missing functionality.  
There's some cool stuff being worked on now.  I might have time to log in 
tonight, but to be honest, I'm pretty tired and somewhat jet-lagged right 
now.

Rock on!
/will

-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.

Re: [Pyblosxom-devel] Problem in startup()

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

Theodore W. Leung wrote:

>What's a good way to do this?  Seems like I need a "no search results file"
>somewhere that can get stuck into the entrylist returned by lucene.
>Otherwise, when we try to generate dataList from filelist there won't be a
>file that getProperties can work on....
>  
>
Just wait for my renderer, and we'll come up with something, With 
renderers done, a plugin can automatically halt processing with a nice 
page, like the statusnotfound.py plugin.

Re: [Pyblosxom-devel] Problem in startup()

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

Theodore W. Leung wrote:

>>Anyway, here's a list of that I wanted to do in startup()
>>1. Look for (yr/mo/da) which must appear in either yr, yr/mo 
>>or yr/mo/da combination
>>2. Process the rest of the URL
>>3. Use index.flavour as the flavour to use and a page to 
>>render(no need 
>>for flav=flavour, though not missing entirely)
>>4. If path or file does not exist, treat query as invalid
>>    
>>
>Do I undestand right? You want to eliminate flav=flavour processing in favor
>of index.flavour in #3?
>
?flav=flavour will still be there, you don't want to break people's 
templates, especially when some of them do pyblosxom and blosxom 
together. I'm just saying that index.flavour is synonymous to ?flav=flavour

>So in 4. what should be the correct behaviour?
>  
>
General blosxom behaviour on this is, render the whole site as per 
normal when something goes wrong, or show header and footer when 
entrylist is empty. This I think is not good IMHO. I'll build a renderer 
RSN, where you can throw messages at it if you do not have entryList, 
etc, to be finalized by me, The least is to throw in a body and title, 
and I'll draw out the header, story and footer based on the template. 
Should be more civilized this way :)

RE: [Pyblosxom-devel] Problem in startup()

[Theodore W. L. <tw...@sa...>]

> -----Original Message-----
> From: pyb...@li...=20
> [mailto:pyb...@li...] On=20
> Behalf Of Wari Wahab
> Sent: Monday, February 10, 2003 3:13 AM
> Cc: pyb...@li...
> Subject: [Pyblosxom-devel] Problem in startup()
>=20
>=20
> See the diff between=20
> http://roughingit.subtlehints.net/pyblosxom-dev/2002/08?flav=3Di
> ndex and=20
> http://roughingit.subtlehints.net/pyblosxom/2002/08?flav=3Dindex
>=20
> The pyblosxom-dev uses
> while re.match(r'^[a-zA-Z0-9]\w*', path_info[0]):
> and pyblosxom:
> while re.match(r'^[a-zA-Z]\w*', path_info[0]):
>=20
> You should get only one entry, but pyblosxom-dev lists all=20
> the entries=20
> from the start till end.
>=20
> This happens because I calculated pi_mo, pi_yr, etc much later at the=20
> end of startup:
>         self.py['pi_yr'] =3D (len(path_info) > 0 and=20
> path_info.pop(0) or '')
>         self.py['pi_mo'] =3D (len(path_info) > 0 and=20
> path_info.pop(0) or '')
>         self.py['pi_da'] =3D (len(path_info) > 0 and=20
> path_info.pop(0) or '')
>=20
> If your the fix eats up the 2002 as an entry match, pi_yr=20
> will never get=20
> anything. You have to change the way the path_info is=20
> processed. I was=20
> going to look into that, and as I said I was kinda lazy while doing=20
> other infrastructure stuff.

I see the problem.  I didn't try it on the index flavor -- probably =
because
I did it so long ago that I forgot about it until I tried to check it =
in.
=20
> Anyway, here's a list of that I wanted to do in startup()
> 1. Look for (yr/mo/da) which must appear in either yr, yr/mo=20
> or yr/mo/da=20
> combination
> 2. Process the rest of the URL
> 3. Use index.flavour as the flavour to use and a page to=20
> render(no need=20
> for flav=3Dflavour, though not missing entirely)
> 4. If path or file does not exist, treat query as invalid

Do I undestand right? You want to eliminate flav=3Dflavour processing in =
favor
of index.flavour in #3?

So in 4. what should be the correct behaviour?

Ted

RE: [Pyblosxom-devel] Problem in startup()

[Theodore W. L. <tw...@sa...>]

> -----Original Message-----
> From: pyb...@li... 
> [mailto:pyb...@li...] On 
> Behalf Of Wari Wahab
> Sent: Monday, February 10, 2003 3:13 AM
> Cc: pyb...@li...
> Subject: [Pyblosxom-devel] Problem in startup()
> 
> 
> Which reminds me, lucene.py should tell the user that the search is 
> invalid if no entries are found too instead of letting people see the 
> default page being rendered, and the user have no clue that 
> their search 
> term did not return any results.
> 

What's a good way to do this?  Seems like I need a "no search results file"
somewhere that can get stuck into the entrylist returned by lucene.
Otherwise, when we try to generate dataList from filelist there won't be a
file that getProperties can work on....

Ted

RE: my issues (was RE: [Pyblosxom-devel] Lucene and comments)

[Theodore W. L. <tw...@sa...>]

> -----Original Message-----
> From: pyb...@li...=20
> [mailto:pyb...@li...] On Behalf Of will
> Sent: Monday, February 10, 2003 7:24 AM
> To: pyb...@li...
> Subject: my issues (was RE: [Pyblosxom-devel] Lucene and comments)
>=20
Please call me Ted...
>=20
> Um, Theodore, did you read the thread from last week=20
> regarding the url handling stuff I was working on that Wari=20
> asked you to read?
>=20

I thought that I did, but on a second reading, I see that I didn't.  My
Apologies.

>=20
> I'm seriously concerned right now.  I think there are way too=20
> many cooks=20
> with their hands in the soup who aren't bothering to=20
> coordinate with the=20
> other cooks.  I go on vacation for a few days and come back to find a=20
> flurry of development (which is fine) which (unless you guys are=20
> communicating off the list--which sucks for coordination) seems to be=20
> totally uncoordinated.
>=20

I'm doing almost all of my communications here on the list.  Blake and I
have exchanged a few messages about logstats.py

>=20
> My basic problems with this project go like this:
>=20
> 1. there are no coding conventions--everyone's using their=20
> own style and=20
> the code base is a mess of several different styles which makes it=20
> difficult to figure out what's going on.

I wasn't aware that we had a coding style, I agree that it would be good =
to
have one.  I don't have enough experience with Python to outline what =
that
should be.  If you or one of the other guys wants to spell this out, I'm
happy to reformat my code to comply.

> 2. people aren't adequately documenting what they're doing. =20
> this is both=20
> specifications that should be written to the devel list so we=20
> can discuss=20
> things BEFORE they happen as well as inline documentation in the code.

I guess this is mostly me.  I wanted to get the lucene stuff checked in, =
and
Wari and Blake seemed to be okay with what I was proposing.  And given =
that
I didn't carefully read what you wrote, I thought what I checked in =
would be
okay.  Obviously not

> 3. there are some fundamental architecture changes that need=20
> to be done. =20
> my first blush impression by looking at the checkin diffs=20
> over the last week, we're duplicating functionality and=20
> calling it different names.

I agree with this.  So maybe the best thing for us to do is back out my
changes and I'll wait until you get done and then figure out how to
integrate my stuff.

>=20
> So what's the deal?  I definitely don't want to be involved=20
> if it's going=20
> to be this chaotic.  I'm totally not down with the "throw=20
> code together=20
> then discuss" method of doing things--I think it's an extremely poor=20
> development model which leads to a very large and unwieldy=20
> code-base with=20
> a lot of funkiness in edge-case scenarios.  It's not like=20
> we're inventing=20
> a totally new wheel here--many of the things we're discussing=20
> have been=20
> done over and over again in other projects.

It helps me to see what changes need to be made when I try to implement
functionality.  I guess my mistake was checking the code into CVS.  Next
time I'll post the diffs to the mailing list and we can talk about what
needs to happen.

> I'll be honest--if this is the way you guys want this to work, then I=20
> can't be involved and I'll bow out.

I think that would be a huge loss for pyblosxom -- you've contributed a =
lot
to what's here.  Let's work out how we want to work together and then =
try to
stick to it.  I promise to spend more time reading e-mails in the =
future.
In the meantime, if you want me to back out my changes, say the word and
I'll do it.

Ted

> /will
>=20
>=20
> On Sun, 9 Feb 2003, Theodore W. Leung wrote:
> >=20
> > Ok,
> >=20
> > I've committed changes that make lucene work in a plugin style way.
> >=20
> > I added a new kind of execute method to api.py, so that the=20
> executed=20
> > handlers can return a list (in the case of lucene, a list=20
> of files). =20
> > I then added two new callback chains, one for CGI and=20
> another for the=20
> > filelist.
> >=20
> > When I added the callback chain for the filelist, I created=20
> a default=20
> > plugin that contains the code for the standard blosxom file=20
> traversal.
> > I'm not sure that I like this approach because it puts the plugin
> > directory back as required.  Seems like it might be better to have
> > pyblosxom.py contain the code and somehow register it, but=20
> the plugin
> > discovery mechanism (as it stands) precludes that.
> >=20
> > Please let me know your thoughts on this.
> >=20
> > I totally don't mind comments that say "this sucks".  Part of the=20
> > reason I asked for feedback was that I didn't like it myself.
> >=20
> > I'll be looking at comments next, but I need to do a little Java=20
> > hacking the rest of today.
> >=20
> > Ted
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something=20
> 2 See! http://www.vasoftware.com=20
> _______________________________________________
> Pyblosxom-devel mailing list Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>=20

RE: [Pyblosxom-devel] Re: my issues

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

> > I'm seriously concerned right now.  I think there are
> > way too many cooks with their hands in the soup who
> > aren't bothering to coordinate with the other cooks.
> I guess what we can do for now is to at least define some 
> form of roles and what each of us can do to contribute to
> pyblosxom.  I for one am trying to make things as modular
> as possible, Ted and Blake are doing comments, and as for
> you, in charge of api functionality.

That sounds about right, although if I have a quick bug-fix,
and the original maintainer of a file doesn't get back to me
in a day or two, I might just check it in myself.  (i.e.
mt2blosxom.py)

Having said that, I'm not going to do a whole lot on comments
until the api and modularity settle down a little.  There's
the back-end stuff which I've been working on, but there's
also front-end stuff which won't be started for a while.

> > I go on vacation for a few days and come back to find a
> > flurry of development (which is fine) which (unless you
> > guys are communicating off the list--which sucks for
> > coordination) seems to be totally uncoordinated.

The development I've been doing has been fairly uncoordinated,
but it's also been available from my website, and explicitly
not been checked in, and there's not a lot of coordination that
needs to be done with the storage part.  I've been developing
the API, and writing an implementation of it.  If the API
changes because of things people need, I'll change the
implementation to fit it.  If someone wants to use the API,
they should let me know (as I've said), and we can talk a
little more about how to do what they want to do.

> > My basic problems with this project go like this:
> > 1. there are no coding conventions--everyone's using their
> >    own style and the code base is a mess of several
> >    different styles which makes it difficult to figure out
> >    what's going on.
> We could solve this by following some coding guidelines, I 
> guess the one you have for lyntin would be a good base to
> start.

My preference is for a coding style that doesn't use tabs, and
uses four-space indents, but I'm flexable.  If I'm modifying
a currently existing file, I follow the style of that file, but
that's a no-brainer.

> > 2. people aren't adequately documenting what they're doing.
> >    this is both specifications that should be written to
> >    the devel list so we can discuss things BEFORE they
> >    happen as well as inline documentation in the code.
> I hope I've given enough information as to what I'm doing so 
> that no one gets lost.

Same here, with the caveat that an example is sometimes the
best way to explain things.  If there's anything about the
storageApi, or the xmlFile implementation you don't understand
and need or want to, please email me off-list, and I'll answer,
and use the answers to create documentation both to put in the
class as comments, and to post to the list, and even to put in
the wiki.

> > 3. there are some fundamental architecture changes that
> >    need to be done.

This is why I'm not working on the front-end.  But I think that
the back-end stuff I am working on is architecture-independant.
Well, mostly architecture-independant, anyways.  Anywhere it
isn't is a bug in the spec.  ;)

> > So what's the deal?  I definitely don't want to be involved
> > if it's going to be this chaotic.  
> I guess you could give us a chance? pyblosxom-devel with all
> the cooks in it are quite young, basically, it's just two
> months old (does it feel like a long time or what?). Heck
> even most of the code contribution is not mine.

I think that the main bit of chaos is the rearchitecting of
the code, and that that will settle down in the fairly near
future.  It's complicated by the other stuff we're doing
(comments, lucene search), but by and large, I think the sets
of items are rather distinct.

> > I'm totally not down with the "throw code together then
> > discuss" method of doing things--I think it's an extremely
> > poor development model which leads to a very large and
> > unwieldy code-base with a lot of funkiness in edge-case
> > scenarios.

Even if the code isn't checked in?  Myself, I prefer to have
code that I can look at and poke while I'm discussion a
proposal, even if (especially if) that code isn't what's
going to be put into CVS.  That was why I asked if I should
check the api in, and that was also why I decided to not do
that, and to let people look at it another way.

> > It's not like we're inventing a totally new wheel here--
> > many of the things we're discussing have been done over
> > and over again in other projects.

Yes, and at least for the stuff I've been doing, I've
been looking at the other projects, and seeing how what
I'm writing compares to them.

> What we need is to give out specs, or throw in working
> diffs before checking it (at least for major changes),
> bug fixes can be checked in as they are found.

That's been the way I've been trying to do stuff.
Have I been doing okay, or have I been slipping?

> > I'll be honest--if this is the way you guys want this
> > to work, then I can't be involved and I'll bow out.
> Don't leave just yet, ok?

I second that.  We need the voice of reason to say stuff
like this, and make us look at what's going on.

Well, that was long.

Later,
Blake.

[Pyblosxom-devel] Chandlog update

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

Hi guys, just a quick note. Please update the Changelog for every new 
feature or important bugfixes worth mentioning when checking in code. 
I've tried to be religious about it, and I hope you guys do it too. Thanks.

[Pyblosxom-devel] Re: my issues

[<su...@ho...>]

On Mon, Feb 10, 2003 at 09:23:48AM -0600, will wrote:
> Um, Theodore, did you read the thread from last week regarding the url
> handling stuff I was working on that Wari asked you to read?

Ah yes, issues that bugs me still.

> I'm seriously concerned right now.  I think there are way too many
> cooks with their hands in the soup who aren't bothering to coordinate
> with the other cooks.  

I guess what we can do for now is to at least define some form of roles
and what each of us can do to contribute to pyblosxom. I for one is
trying to make things as modular as possible, Ted and Blake are doing
comments, and as for you, in charge of api functionality.

> I go on vacation for a few days and come back to find a flurry of
> development (which is fine) which (unless you guys are communicating
> off the list--which sucks for coordination) seems to be totally
> uncoordinated.

As far as I know, I did not communicate off the list, as far as
possible.

> My basic problems with this project go like this:
> 1. there are no coding conventions--everyone's using their own style
>    and the code base is a mess of several different styles which makes
>    it difficult to figure out what's going on.

We could solve this by following some coding guidelines, I guess the one
you have for lyntin would be a good base to start.

> 2. people aren't adequately documenting what they're doing.  this is
>    both specifications that should be written to the devel list so we
>    can discuss things BEFORE they happen as well as inline
>    documentation in the code.

I hope I've given enough information as to what I'm doing so that no one
gets lost.

> 3. there are some fundamental architecture changes that need to be
>    done.  my first blush impression by looking at the checkin diffs
>    over the last week, we're duplicating functionality and calling it
>    different names.

Can you point out which of these fires needs to be put out? Yeah, being
new to python development doesn't help, but at least I do try my best to
point out what will break big picture.

> So what's the deal?  I definitely don't want to be involved if it's
> going to be this chaotic.  

I guess you could give us a chance? pyblosxom-devel with all the cooks
in it are quite young, basically, it's just two months old (does it feel
like a long time or what?). Heck even most of the code contribution is
not mine.

> I'm totally not down with the "throw code together then discuss"
> method of doing things--I think it's an extremely poor development
> model which leads to a very large and unwieldy code-base with a lot of
> funkiness in edge-case scenarios.  It's not like we're inventing a
> totally new wheel here--many of the things we're discussing have been
> done over and over again in other projects.

What we need is to give out specs, or throw in working diffs before
checking it (at least for major changes), bug fixes can be checked in as
they are found.

> I'll be honest--if this is the way you guys want this to work, then I
> can't be involved and I'll bow out.

Don't leave just yet, ok?

my issues (was RE: [Pyblosxom-devel] Lucene and comments)

[will <wi...@bl...>]

Um, Theodore, did you read the thread from last week regarding the url
handling stuff I was working on that Wari asked you to read?


I'm seriously concerned right now.  I think there are way too many cooks 
with their hands in the soup who aren't bothering to coordinate with the 
other cooks.  I go on vacation for a few days and come back to find a 
flurry of development (which is fine) which (unless you guys are 
communicating off the list--which sucks for coordination) seems to be 
totally uncoordinated.


My basic problems with this project go like this:

1. there are no coding conventions--everyone's using their own style and 
the code base is a mess of several different styles which makes it 
difficult to figure out what's going on.

2. people aren't adequately documenting what they're doing.  this is both 
specifications that should be written to the devel list so we can discuss 
things BEFORE they happen as well as inline documentation in the code.

3. there are some fundamental architecture changes that need to be done.  
my first blush impression by looking at the checkin diffs over the last
week, we're duplicating functionality and calling it different names.


So what's the deal?  I definitely don't want to be involved if it's going 
to be this chaotic.  I'm totally not down with the "throw code together 
then discuss" method of doing things--I think it's an extremely poor 
development model which leads to a very large and unwieldy code-base with 
a lot of funkiness in edge-case scenarios.  It's not like we're inventing 
a totally new wheel here--many of the things we're discussing have been 
done over and over again in other projects.

I'll be honest--if this is the way you guys want this to work, then I 
can't be involved and I'll bow out.

/will


On Sun, 9 Feb 2003, Theodore W. Leung wrote:
> 
> Ok,
> 
> I've committed changes that make lucene work in a plugin style way.
> 
> I added a new kind of execute method to api.py, so that the executed
> handlers can return a list (in the case of lucene, a list of files).  I
> then added two new callback chains, one for CGI and another for the
> filelist.
> 
> When I added the callback chain for the filelist, I created a default
> plugin that contains the code for the standard blosxom file traversal.  
> I'm not sure that I like this approach because it puts the plugin
> directory back as required.  Seems like it might be better to have
> pyblosxom.py contain the code and somehow register it, but the plugin
> discovery mechanism (as it stands) precludes that.
> 
> Please let me know your thoughts on this.
> 
> I totally don't mind comments that say "this sucks".  Part of the reason
> I asked for feedback was that I didn't like it myself.
> 
> I'll be looking at comments next, but I need to do a little Java hacking
> the rest of today.
> 
> Ted

[Pyblosxom-devel] Entryparsers, what are they?

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

I've checked in some code today, basically infrastucture stuff. But what
the heck is infrastructure and what am I actually doing. I've got to
answer this question first I guess.

There are a few things I want to do, one of them, the external cron job
thing and we talked about previously. But as an external entity, I
wanted to reuse a lot of pyblosxom code if possible, and if I added in a
new feature or two, I would be able to get all those features
immediately without changing a line of code.

Here's what I planned for (as much as I can remember).
1. Structured caching
2. Multiple entry file types
3. Renderers
4. XMLRPC plugins

And some other things I can't remember off hand.

1. External programs should use the cache if possible to get important
   entry data stuff. Cache are mostly post formatted data, processed by
   preformatters, or can contain data processed by entryparsers. This is
   to ensure that there's no slowdown in whatever data we deal with.
   This is done with the libs.cache module, very simple to get data
   from.

2. What if our external program kicks off before an entry gets cached?
   What if the entries are not in txt format? That's where entryparsers
   comes in. Entryparsers right now look at .txt files, but later in its
   life it will be able to get .xhtml (where you get the title off a
   <title> tag and metadata out of a <meta> tag. Easy as that, of course
   if you use xhtml, your input must be a valid xhtml possibly verified
   by some external entity (emacs?) the body text is available from the
   <body></body> tag (duh!:) If I'm free, I read up on DOM and see if I
   can create my XHTML parser.

   Possibility are endless here, word documents (yeah you have to
   convert them to html), pdfs, latex (huh?) whatever you can throw at
   it as long as you have the parser for it, it should work. If you look
   at http://roughingit.subtlehints.net/pyblosxom-dev and compare the
   output of http://roughingit.subtlehints.net/pyblosxom you'll see
   entryparsers at work, I created a dummy xhtml.py which is a copy of
   txt.py, you'll see that in the permalink(#), you'll see
   text.xhtml.html as the link, of course following it -
   http://roughingit.subtlehints.net/pyblosxom/test.xhtml.html, does not
   work as I still have to change startup() and getProperties a bit as
   they hardcode the txt extension. This is still a work in progress,
   but it's getting there.

   What do you think? I need feedback here

3. Renderers - These are page generators, basically they are the code in
   libs.pyblosxom.PyBlosxom.run() after the Walk, now called
   fileListHandler(), I want to use another object for that, something
   around the structure of how cache/ and preformatters/ work.

   Renderers should be able to handle some input, and produce an output
   in a query, together using entryparser and cache, I should be able to
   change the way templating works, standard blosxom, or go all out with
   Cheetah, you name it any hacker should be able to extend it. If
   people love MovableType (HTML::Template) style of using templates
   someone would easily hack out such code without modifying pyblosxom.
   Is this a good idea?

4. XMLRPC.py is fixed right now, I need them to be pluggable in order to
   support trackback queries, as well as a pingback ping server. If the
   user want's bloggerAPI I should be able to drop that in and make it
   optional.

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

Re: [Pyblosxom-devel] What Vellum has to offer?

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

* Blake Winton <bl...@ph...> [030210 07:35]:
> Okay, my initial thoughts are: The Audience is pretty much what I had
> come up with before, although that's a great name for it.

Audience, that's a great name! Let's use Vellum :)

> The custom fields are an interesting idea, but I think they're a
> hang-over from C, since in Python you can add any fields you want to
> any object, so there should be no reason to have them there.

You can add custom fields? Hmm, entries can add custom variable, want
more fields, we can do foo(**kwargs), what happens after that?

> I can see what it's trying to do with the vellum.functions and it's a
> neat idea.  We might want to use that, Wari.  

That should be easy to do, right Will :) Will told me that our Callback
transformation is more powerful, also ours seems limited now cause we
have very little thinks to callback with our api, but it will grow I
assure you :)

>> pickle, db, etc...
> Easier to write to the data files with vi?

for DBM:
db_dump -p dbfile > db.dump
vim db.dump
db_load db.dump etc etc

for pickle:
import pickle :)

Stupid, but hey :)

> As a programmer, none of you will have to write the code to read or
> write XML.  I'll do all of that coding for you.  In fact, I'm half
> done.  http://www.latte.ca/cgi-bin/source.py?name=file

Great piece of work there :)

> I did some tests with adding and removing data, and it was on the
> order of 0.02 ms to call get, passing it a type of Storage.COMMENTS on
> a document with three comments.  I don't know if that scales yet, but
> I've got a whack of sample data from Wari, so I'll run some more
> tests, and see what happens.  I am, however, cautiously optimistic.

Go load a page with the harry potter porn comments :) You'll see how
fast it can render 100 comments

I've got other sample data with 516 entries and 1376 comments and
growing :)

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

Re: [Pyblosxom-devel] Lucene and comments

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

* Blake Winton <bl...@ph...> [030209 22:36]:
> 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" -->'

I need to explain my entryparsers :) just wait.

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

Hehehe, you are one cool dude :)

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

I don't have anything to contribute here, you guys can go ahead, I'm
dealing with 'infrastructure' stuff now which I'll explain in another
email

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

Re: [Pyblosxom-devel] Lucene and comments

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

* Theodore W. Leung <tw...@sa...> [030210 08:07]:
> I've committed changes that make lucene work in a plugin style way.
> 
> I added a new kind of execute method to api.py, so that the executed
> handlers can return a list (in the case of lucene, a list of files).  I then
> added two new callback chains, one for CGI and another for the filelist.

Hi sir, I wanted the lucene indexing to recognize other files using
entryparsers if possible, you game for it, it would somehow mean that
index.sh would be index.py, pushing data to the lucene java program. I
don't think it's an easy task though, but hey, who knows?

I don't want this to be an immediate thing yet, but when you can throw
in all sorts of file in a blosxom directory, you wont want to be limited
by a .txt only implementation.

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

[Pyblosxom-devel] Problem in startup()

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

See the diff between 
http://roughingit.subtlehints.net/pyblosxom-dev/2002/08?flav=index and 
http://roughingit.subtlehints.net/pyblosxom/2002/08?flav=index

The pyblosxom-dev uses
while re.match(r'^[a-zA-Z0-9]\w*', path_info[0]):
and pyblosxom:
while re.match(r'^[a-zA-Z]\w*', path_info[0]):

You should get only one entry, but pyblosxom-dev lists all the entries 
from the start till end.

This happens because I calculated pi_mo, pi_yr, etc much later at the 
end of startup:
        self.py['pi_yr'] = (len(path_info) > 0 and path_info.pop(0) or '')
        self.py['pi_mo'] = (len(path_info) > 0 and path_info.pop(0) or '')
        self.py['pi_da'] = (len(path_info) > 0 and path_info.pop(0) or '')

If your the fix eats up the 2002 as an entry match, pi_yr will never get 
anything. You have to change the way the path_info is processed. I was 
going to look into that, and as I said I was kinda lazy while doing 
other infrastructure stuff.

Anyway, here's a list of that I wanted to do in startup()
1. Look for (yr/mo/da) which must appear in either yr, yr/mo or yr/mo/da 
combination
2. Process the rest of the URL
3. Use index.flavour as the flavour to use and a page to render(no need 
for flav=flavour, though not missing entirely)
4. If path or file does not exist, treat query as invalid

Which reminds me, lucene.py should tell the user that the search is 
invalid if no entries are found too instead of letting people see the 
default page being rendered, and the user have no clue that their search 
term did not return any results.

Theodore W. Leung wrote:

>Please do show me...
>  
>

Re: [Pyblosxom-devel] What Vellum has to offer?

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

* Kai Hendry <he...@cs...> [030210 03:04]:
> On the subject of comments and what have you, have any of you had a
> look at Vellum ?

I really think vellum is to pyblosxom as MT is to blosxom. It's a
different creature altogether, different focus here and there.

So if I think MT is great, why do blosxom users use perl blosxom when MT
is quite a complete package. Different audience here Kai.

> I prefer to write my blogs with vim, i.e. not using a web ui. However
> I hope Pyblosxom can take on some of the cool stuff Vellum has to
> offer.  For example, I have a friend who needs a Web UI to blog, I
> will install Vellum for him.

If you want pyblosxom with webui, it's there in contrib/weblog-add.py,
you can mould it and shape it to whatever you like, heck I think you can
use it to start a subproject, webui for blosxoms :) supports every known
blosxom out there.

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

RE: [Pyblosxom-devel] Lucene and comments

[Theodore W. L. <tw...@sa...>]

Ok,

I've committed changes that make lucene work in a plugin style way.

I added a new kind of execute method to api.py, so that the executed
handlers can return a list (in the case of lucene, a list of files).  I =
then
added two new callback chains, one for CGI and another for the filelist.

When I added the callback chain for the filelist, I created a default =
plugin
that contains the code for the standard blosxom file traversal.  I'm not
sure that I like this approach because it puts the plugin directory back =
as
required.   Seems like it might be better to have pyblosxom.py contain =
the
code and somehow register it, but the plugin discovery mechanism (as it
stands) precludes that.

Please let me know your thoughts on this.

I totally don't mind comments that say "this sucks".  Part of the reason =
I
asked for feedback was that I didn't like it myself.  =20

I'll be looking at comments next, but I need to do a little Java hacking =
the
rest of today.

Ted

> -----Original Message-----
> From: pyb...@li...=20
> [mailto:pyb...@li...] On=20
> Behalf Of Wari Wahab
> Sent: Sunday, February 09, 2003 7:02 AM
> To: tw...@sa...
> Cc: pyb...@li...
> Subject: Re: [Pyblosxom-devel] Lucene and comments
>=20
>=20
> Theodore W. Leung wrote:
>=20
> >I'm back and caught up and ready to tackle a few things.
> >
> >#1.  I'm trying to figure out what is the best way to integrate my=20
> >Lucene code.For the file list, we need to turn the regular directory=20
> >walk into the default behavior (last in the chain) and let=20
> each plugin=20
> >before that return a list.  If any plugin in the  chain=20
> returns a list,=20
> >then handler processing is done.
> >
> This was discuss @=20
> http://sourceforge.net/mailarchive/forum.php?thread_id=3D1613664
> &forum_id=3D24361=20
> but still there is no real solution yet. If you've got some ideas, or=20
> working code, we could try test it out and see if we can use=20
> it for all=20
> situations.
>=20
> >#2.   For comments I have the following issues
> >We need a way to display a single article in a page, (so that we can=20
> >put the comment form up).  This probably just means invoking a=20
> >different template for the single article case.
> >
> Yup.
>=20
> >We (again) need a way to handle the comment CGI form post=20
> (probably via=20
> >the chain above).
> > =20
> >
> Again, the need for your point #1. :) To make life simpler, I'm=20
> suggesting a comment.cgi type of program to handle comments.=20
> We can make=20
> pyblosxom handle everything, but as feedback mechanism goes,=20
> you'll find=20
> trackback and pingback requiring xmlrpc mechanism to input=20
> feedback data.
>=20
> Then you'll need some management of feedback data, especially=20
> deleting=20
> feedback spam if necessary (of course to know if you're=20
> spammed, to need=20
> to mail every feedbacks to the users).
>=20
> I'm not sure what Blake have in mind, he would also like pyblosxom to=20
> handle POST and GET requests too. XMLRPC uses POST too, incompatible=20
> with GET requests and cgi module won't handle it.
>=20
> >We need a way to display the comment / trackback / pingback count=20
> >(retreived from the storage api) in story.html (via a=20
> variable) -- so=20
> >every iteration through valid_list needs to be able to talk to the=20
> >storage api.  This seems like another place for a callback chain.
> >
> Counts can be done by the standard load() plugins, iterating=20
> thru values=20
> of entryList at each call by using a standard incremental style of=20
> iteration. The plugin would call storageAPI to get relevant data of=20
> comment counts and what nots.
>=20
> >I just wanted to get your thoughts on this before I plunge ahead.
> > =20
> >
> More things to consider, how do you tell pyblosxom that you want to=20
> disable comments on a particular entry? Would some meta data=20
> like: #comments 0 in an entry work in order to disable=20
> comments? Also, what about making=20
> comments inactive for a particular entry as well? In my other blog I=20
> have to delete one entry because it recieved 100s of stupid=20
> comments and=20
> I can't disable it in MT (MT will fix that in 2.6)?
>=20
> Sorry if this mail sounds negative, I'mm all for feedbacks, I want it=20
> badly, but it does not seem to be an easy task with all these issue=20
> lying around.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something=20
> 2 See! http://www.vasoftware.com=20
> _______________________________________________
> Pyblosxom-devel mailing list Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>=20

RE: [Pyblosxom-devel] What Vellum has to offer?

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

> On the subject of comments and what have you, have any
> of you had a look at Vellum ?

Not yet, but I will now...

Okay, my initial thoughts are:
The Audience is pretty much what I had come up with
before, although that's a great name for it.

The custom fields are an interesting idea, but I think
they're a hang-over from C, since in Python you can add
any fields you want to any object, so there should be
no reason to have them there.

It's tied down to bsddb, which bothers me, because I
can't hand-edit the files, and because people are
suggesting that it get replaced with other things.
http://mail.python.org/pipermail/patches/2002-July/008828.html

I can see what it's trying to do with the vellum.functions
and it's a neat idea.  We might want to use that, Wari.
(calling vellum.cgi?a=foo will run the function named
 vellum.functions.foo, apparently with the form as a
 parameter.  I'm not sure I entirely like it, but it's
 very similar in concept to our py dictionary.  Actually,
 I think the vellum.Entry.Entry is closer to our py
 dictionary, but you get the idea.)

> p.s. I do prefer pickle over xml. It is so much easier.

Easier to write to the data files with vi?

As a programmer, none of you will have to write the code
to read or write XML.  I'll do all of that coding for you.
In fact, I'm half done.
http://www.latte.ca/cgi-bin/source.py?name=file

If anyone wants to write the code that uses it, let me
know, and I'll forward you my test scripts, which will
provide a pretty clear explanation of how I think the
storageApi will be used.

I did some tests with adding and removing data, and it
was on the order of 0.02 ms to call get, passing it a
type of Storage.COMMENTS on a document with three comments.
I don't know if that scales yet, but I've got a whack of
sample data from Wari, so I'll run some more tests, and
see what happens.  I am, however, cautiously optimistic.

Further changes:
Implement store and load in the Storage class, since the
format to export and import will be the same throughout
all the storage implementations.  Also, move the marshal
and unmarshal code up into the base, since it will be
what's used to implement store and load.

Oh, and to make everyone feel a little better, the page at
http://www.python.org/doc/current/lib/module-xml.dom.minidom.html
(which is the xml-api I'm using) says "New in version 2.0."
So it seems like everything we need is included.

Later,
Blake.

[Pyblosxom-devel] What Vellum has to offer?

[Kai H. <he...@cs...>]

On the subject of comments and what have you, have any of you had a look
at Vellum ?

http://www.kryogenix.org/code/vellum/

I tried it out in a fever yesterday, and I found it quite good. The way
it handles plugins was particularly impressive. Much neater than
Pyblosxom. :)

Anyway, one of the plugins is "Comments":
http://www.kryogenix.org/code/vellum/plugins/comments.py
It makes use of another plugin, called "Audience":
http://www.kryogenix.org/code/vellum/plugins/audience.py

I like how it looks : 
http://www.kryogenix.org/days/414.html

I prefer to write my blogs with vim, i.e. not using a web ui. However I
hope Pyblosxom can take on some of the cool stuff Vellum has to offer.
For example, I have a friend who needs a Web UI to blog, I will install
Vellum for him.

Regards,
-Kai Hendry
p.s. I do prefer pickle over xml. It is so much easier.

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.

Re: [Pyblosxom-devel] Lucene and comments

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

Theodore W. Leung wrote:

>I'm back and caught up and ready to tackle a few things.
>
>#1.  I'm trying to figure out what is the best way to integrate my Lucene
>code.For the file list, we need to turn the regular
>directory walk into the default behavior (last in the chain) and let each
>plugin before that return a list.  If any plugin in the  chain returns a
>list, then handler processing is done.
>
This was discuss @ 
http://sourceforge.net/mailarchive/forum.php?thread_id=1613664&forum_id=24361 
but still there is no real solution yet. If you've got some ideas, or 
working code, we could try test it out and see if we can use it for all 
situations.

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

>We (again) need a way to handle the comment CGI form post (probably via the
>chain above).
>  
>
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.

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

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.

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

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

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