pyblosxom-devel — Development Mailing List for pyblosxom

[Pyblosxom-devel] Egads! Bugs?

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

BTW, I cc to pyblosxom-devel as this topic spawns of to something that
devel list might me interested in.

* Blake Winton <bl...@ph...> [030204 22:57]:
> So, have you gotten any bug reports recently?

Being a python software (unlike perl blosxom) I don't have that much
users giving me bug reports, if they have, they included a patch for it
(interesting indeed).

> Are you using any of the SourceForge features, other than the mailing
> lists?  

Tried to but with miniscule user base, I don't see sf.net to be a main
focal point of activity.

> I notice that they have a place for bug tracking and another for
> documentation.  

The documentation thingy is not as good as a wiki I guess, that's why I
have a wiki site for documentation. Anyone who feels that the docs is
lacking can always contribute if they need to.

> If anyone is submitting bugs, I'd love to help track them down and
> fix them.  (Of course, if no-one is submitting bugs, good job! ;)

Bugs, what bugs? pyblosxom is 1000% bug free :) NOT. hehe. There is one
or two lying about.

1. Entry files that starts with a digit will fail to get picked up by
   pyblosxom when using a single entry link:
   See:
   http://roughingit.subtlehints.net/pyblosxom/2003/Jan/31#1044019277
   http://roughingit.subtlehints.net/pyblosxom/development/1044019277.html

   The second url borks. This bug requires some modification (or even
   refactoring) of libs.Pyblosxom.startup() or could even be done better
   with a urlhandler() thingy, which is not available yet. Which is why
   I didn't fix this before releasing 0.6

2. Proper url handler to handle things queries like 2003/Jan/index.html
   or /development/index.html

I think the main point of this is that handling or URLs must be fixed or
pluggable so that we can do sane URL handlings or handle other stuff
like comments or searches, etc..

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

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

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

> Responding to some comments from Wari, Our Glorious Leader:
> > I need an API for storage.
> 
> Okay, here's a first pass at the storage api.
> ----------------->8 storageApi.py 8<--------------------
> """
> This module defines the api that any class implementing storage must
> conform to.
> """
> class Storage:
> 
>     # Storage types.
>     COMMENT         = 1
>     TRACKBACK       = 2
>     PINGBACK        = 3
>     SENT_TRACKBACK  = 4
>     SENT_PINGBACK   = 5
> 
>     def allFilter( entry ):
>         return true
> 
>     def get( self, type, entryId, filter=allFilter ):
>         # Returns a list of all the data for that entry,
>         # filtered by the filter.
>         pass
> 
>     def store( self, type, entryId, data ):
>         # Stores a bit of data of the specified type for the
>         # passed-in entry.
>         pass
> 
>     def search( self, searchTerm, type=None, entryId=None ):
>         # Searches in the specified type and entry (if supplied)
>         # for data containing the passed-in search term.
>         pass
> ----------------->8 storageApi.py 8<--------------------

And some day I'll remember to not hold down the Control key when
I hit enter.  Anyways, what I wanted to say was:

1) Does this fulfill all of our needs in terms of storing and
   retrieving comments/trackbacks/pingbacks/etc?

2) Is it easy enough to use, or can it be made easier?

3) Is it reasonable to implement, or nigh impossible?

I think most of the trickyness would come in writing filters.
Oh, and there's currently no simple way to sort the data, but
if we returned the bit of data as a tuple containing the type,
and whatever else we could parse out, then a sorter would be
fairly simple to write.

Any and all comments appreciated.

Later,
Blake.

[Pyblosxom-devel] Supporting comments, etc.

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

Responding to some comments from Wari, Our Glorious Leader:
> I need an API for storage.

Okay, here's a first pass at the storage api.
----------------->8 storageApi.py 8<--------------------
"""
This module defines the api that any class implementing storage must
conform to.
"""
class Storage:

    # Storage types.
    COMMENT         = 1
    TRACKBACK       = 2
    PINGBACK        = 3
    SENT_TRACKBACK  = 4
    SENT_PINGBACK   = 5

    def allFilter( entry ):
        return true

    def get( self, type, entryId, filter=allFilter ):
        # Returns a list of all the data for that entry,
        # filtered by the filter.
        pass

    def store( self, type, entryId, data ):
        # Stores a bit of data of the specified type for the
        # passed-in entry.
        pass

    def search( self, searchTerm, type=None, entryId=None ):
        # Searches in the specified type and entry (if supplied)
        # for data containing the passed-in search term.
        pass
----------------->8 storageApi.py 8<--------------------

Re: [Pyblosxom-devel] category listings

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

will wrote:

>I like the idea and I think the implementation should definitely get
>checked in.  That solves my use case in a nicely general way that's tied 
>to the flavors themselves.
>  
>
So let it be written, so let it be done.

:)

Re: [Pyblosxom-devel] category listings

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

I like the idea and I think the implementation should definitely get
checked in.  That solves my use case in a nicely general way that's tied 
to the flavors themselves.

I wouldn't make it a plugin though.  I think that's a necessary element of 
pyblosxom configuration and as such shouldn't be a plugin.

Nice!
/will


On Tue, 28 Jan 2003, Wari Wahab wrote:
> 
> I've done this already, if you were to check out 
> http://roughingit.subtlehints.net/pyblosxom/weblogs?flav=index you'll 
> see that 41 entries are listed. I've got the index template for this to 
> show the data, in addition to that, I used a config.index flavour file, 
> which now contains two lines of configuration data:
> ------------------------
> num_entries 999
> blog_title Indexes, indexes my friend
> ------------------------
> You'll see the data reflected nicely, the change is basically in 
> getFlavours() code. My question is this:
> 1. Do we agree on this?
> 2. Can this be a plugin instead?
> 
> Here's the diff for you to try out on your installations:
> ------------------------------------------------
> diff -u -r1.12 pyblosxom.py
> --- pyblosxom.py        22 Jan 2003 14:27:43 -0000      1.12
> +++ pyblosxom.py        28 Jan 2003 11:36:14 -0000
> @@ -94,7 +94,7 @@
>          # End of ugly portion! Yucks :)
>          # Look for flavours in datadir
> 
> -        pattern = 
> re.compile(r'(content_type|head|date_head|date_foot|foot|story)\.' + taste)
> +        pattern = 
> re.compile(r'(config|content_type|head|date_head|date_foot|foot|story)\.' 
> + taste)
>          flavourlist = tools.Walk(self.py['root_datadir'], 1, pattern)
>          if not flavourlist:
>              flavourlist = tools.Walk(self.py['datadir'], 1, pattern)
> @@ -108,6 +108,15 @@
>         
>          if not flavours.has_key(taste):
>              taste = 'error'
> +
> +        if flavours[taste].has_key('config'):
> +            for line in flavours[taste]['config'].split('\n'):
> +                s = 
> line.strip();                                                                                         
> +                if s != 
> '':                                                                                               
> +                    match = re.match(r'(\w+)\s+(.*)', line)
> +                    if match:
> +                        self.py[match.groups()[0]] = 
> match.groups()[1].strip()
> +           
>          return flavours[taste]
> 
>      def getProperties(self, filename, root):

Re: [Pyblosxom-devel] category listings

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

Wari Wahab wrote:

> Here's the diff for you to try out on your installations:

Sheesh, this is the ugliest copy and pasted diff I've ever seen :) 
Adjust accordingly.

Re: [Pyblosxom-devel] category listings

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

Wari Wahab wrote:

>* will <wi...@bl...> [030127 13:49]:
>  
>
>>>This is a limitation that should be addressed by a template (it's
>>>the template problem domain). But the only thing is that blosxom
>>>templates are not that powerful to do such things.
>>>      
>>>
>>Mmmm...  Perhaps we should have template entries in the ini file that
>>dictate properties for those templates?
>>    
>>
>Too many places to do things, I was thinking of something like
>feature.flavour files that override certain pyblosxom variables.
>
>A feature.index (for example in my indexes) could contain things like:
>
>num_entries all
>foo bar
>etc etc
>blog_title My Little Foo Blog :)
>
>Let me think about this, and see how useful can this be.
>
I've done this already, if you were to check out 
http://roughingit.subtlehints.net/pyblosxom/weblogs?flav=index you'll 
see that 41 entries are listed. I've got the index template for this to 
show the data, in addition to that, I used a config.index flavour file, 
which now contains two lines of configuration data:
------------------------
num_entries 999
blog_title Indexes, indexes my friend
------------------------
You'll see the data reflected nicely, the change is basically in 
getFlavours() code. My question is this:
1. Do we agree on this?
2. Can this be a plugin instead?

Here's the diff for you to try out on your installations:
------------------------------------------------
diff -u -r1.12 pyblosxom.py
--- pyblosxom.py        22 Jan 2003 14:27:43 -0000      1.12
+++ pyblosxom.py        28 Jan 2003 11:36:14 -0000
@@ -94,7 +94,7 @@
         # End of ugly portion! Yucks :)
         # Look for flavours in datadir

-        pattern = 
re.compile(r'(content_type|head|date_head|date_foot|foot|story)\.' + taste)
+        pattern = 
re.compile(r'(config|content_type|head|date_head|date_foot|foot|story)\.' 
+ taste)
         flavourlist = tools.Walk(self.py['root_datadir'], 1, pattern)
         if not flavourlist:
             flavourlist = tools.Walk(self.py['datadir'], 1, pattern)
@@ -108,6 +108,15 @@
        
         if not flavours.has_key(taste):
             taste = 'error'
+
+        if flavours[taste].has_key('config'):
+            for line in flavours[taste]['config'].split('\n'):
+                s = 
line.strip();                                                                                         
+                if s != 
'':                                                                                               
+                    match = re.match(r'(\w+)\s+(.*)', line)
+                    if match:
+                        self.py[match.groups()[0]] = 
match.groups()[1].strip()
+           
         return flavours[taste]

     def getProperties(self, filename, root):

Re: [Pyblosxom-devel] New entry triggered events.

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

will wrote:

>Oh--I didn't know about that directory.  I'm thinking we should move the 
>existing plugins to that directory so that people can opt-in to the ones 
>they want.  Unless you're thinking that there would be a series of plugins 
>that almost everyone will want (calendar, categories, archives, comments, 
>(track|ping)backs...)?
>  
>
Thing that write to a file or is slow in execution, or not something 
everyone would need (like the 404 error generator or the conditional 
HTTP) will have to be in the contrib/plugins/ directory, in the case of 
comments or feedback modules where there are going to be more than one 
file involved, it should stay in a contrib/xxxx/ directory and should 
contain some documentation to it. Agreed?

>Maybe we should split this from the rest of pyblosxom almost into its own 
>subproject with its own CVS tree.
>  
>
Yes, I'm thinking about this as well, hence I want a name for it that we 
can agree (pyblosxom-extensions, etc)

>There are varying degrees of vocal users, though.  There are vocal users 
>who correctly point out that a portion of the architecture is ugly and do 
>so over and over again, 
>
They will have to suggest and give some diffs for proof of concept. I 
know pyblosxom is ugly, it was ugly as I did it without planning 
following blosxom.

>and there are the vocal users who either haven't 
>read the documentation or they have fundamental differences in how they 
>see the project.
>
Documentation is lacking, yes :) I do try to give the best of my time 
for it.

>I don't think it makes sense to cater to either category.  Though in
>regards to the first category of vocal users, it's better to fix the issue
>before they get vocal because they can be a pain in the ass and no one
>likes bad architecture.
>  
>
Yeah, I don't like it too, blame it on me for being a python newbie 
trying to take on such a project :)

>However, with the contrib directory, this becomes a moot point.
>  
>
:)

>There's a pretty severe lack of documentation for pyblosxom.  This is both
>user documentation as well as project documentation.  For instance, no
>where can I find what pyblosxom's purpose and goals are.  What is the
>target audience?  What should someone know before running pyblosxom?  
>What requirements are there for running pyblosxom?
>  
>
The main documentation for pyblosxom is at 
http://wiki.subtlehints.net/moin/PyBlosxom which I try my best updating, 
it got tiring after a while, but I do update here and there whenever 
possible.

>I think we're going to start attracting users like Kai who will notice the
>lack of documentation and will just start asking the same questions over
>and over again on the list.
>  
>
Hey, Kai actually did some documentation on the Wiki site, See: 
http://wiki.subtlehints.net/moin/PyBlosxom_2fExtendingPyBlosxom_2fPreFormatters_2fGenericWiki 
actually it's a copy from my mails, whatever info I give from my blog, I 
tried to copy it over there as well. And this: 
http://wiki.subtlehints.net/moin/PyBlosxom_2fExtendingPyBlosxom_2fPlugIns 
need some input too :)

>I'm not really sure what to do about this.  There doesn't seem to be a
>central project page for pyblosxom other than the roughingit site which is
>a blog and not really conducive to solid project documentation.
>  
>
I still think the wiki page should be the site documentation where 
everyone can contribute.

BTW, yeah the wiki was linked by my site, probably too low down the 
menu, or people don't know what a wiki is :)

Re: [Pyblosxom-devel] New entry triggered events.

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

On Tue, 28 Jan 2003, Wari Wahab wrote:
>
> I'm thinking of something like what we do with the contrib/plugins/ 
> thing, if it's a feature a person running pyblosxom.cron wants, he'll 
> copy that plugin in the pyblosxom.cron specific directory. In a way, 
> that'll 'activate' the plugin. No files to edit except probably in the 
> plugin itself, probably to define certain paths, etc. I don't think it 
> needs to register itself to api.py, but it can use it if the need be.

Oh--I didn't know about that directory.  I'm thinking we should move the 
existing plugins to that directory so that people can opt-in to the ones 
they want.  Unless you're thinking that there would be a series of plugins 
that almost everyone will want (calendar, categories, archives, comments, 
(track|ping)backs...)?


> I'm not saying delete the ones you don't need, but put in what you want 
> from a source of compatible plugins like what you get in 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyblosxom/pyblosxom/contrib/plugins/ 
> where there is a list of plugins some user may want, but not others, 
> copy what you need to libs/plugins/
> 
> Of course pyblosxom.cron would need to have it's own plugins and 
> contrib/plugins type of directories. This is much easier than modifying 
> api.py or config.py for whatever plugins you want to opt in.

Maybe we should split this from the rest of pyblosxom almost into its own 
subproject with its own CVS tree.


> :)  No matter how you try to please them, vocal users will be vocal, no 
> matter what tool we're using.

There are varying degrees of vocal users, though.  There are vocal users 
who correctly point out that a portion of the architecture is ugly and do 
so over and over again, and there are the vocal users who either haven't 
read the documentation or they have fundamental differences in how they 
see the project.

I don't think it makes sense to cater to either category.  Though in
regards to the first category of vocal users, it's better to fix the issue
before they get vocal because they can be a pain in the ass and no one
likes bad architecture.

However, with the contrib directory, this becomes a moot point.

 
> Right now the user base for pyblosxom is users that understand python I 
> think. Those who don't know python will probably not use pyblosxom as 
> they might not get pyblosxom libraries to byte compile, thus slowing 
> down the whole thing. These people should try out the super fast PHP 
> blosxom kind, or the kind of cool perl blosxom :) pyblosxom blog have 
> more features than I can list (I probably should set up a page listing 
> them).
> 
> I do expect the users to know what they are getting into installing a 
> blosxom type blog engine, as blosxom is no man's land when you compare 
> it with, say, MT :)
> 
> I just wanted a weblog for work (and now a replacement for my main weblog).

There's a pretty severe lack of documentation for pyblosxom.  This is both
user documentation as well as project documentation.  For instance, no
where can I find what pyblosxom's purpose and goals are.  What is the
target audience?  What should someone know before running pyblosxom?  
What requirements are there for running pyblosxom?

I think we're going to start attracting users like Kai who will notice the
lack of documentation and will just start asking the same questions over
and over again on the list.

I'm not really sure what to do about this.  There doesn't seem to be a
central project page for pyblosxom other than the roughingit site which is
a blog and not really conducive to solid project documentation.

/will

Re: [Pyblosxom-devel] New entry triggered events.

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

will wrote:

>Or alternatively, we could provide excplicit plugin importing via the 
>config.py or ini files.  I'm actually thinking we should do that instead 
>of dropping them in the directory.  Currently there's no way to have a 
>module in the directory and not have it loaded.  I think it would be 
>better to have an opt-in approach rather than an opt-out approach.
>  
>
I'm thinking of something like what we do with the contrib/plugins/ 
thing, if it's a feature a person running pyblosxom.cron wants, he'll 
copy that plugin in the pyblosxom.cron specific directory. In a way, 
that'll 'activate' the plugin. No files to edit except probably in the 
plugin itself, probably to define certain paths, etc. I don't think it 
needs to register itself to api.py, but it can use it if the need be.

>Also, I'm thinking that we're better off with just one configuration file 
>instead of two.  Then we can provide verbose directions about how to 
>adjust the configuration and what to comment and uncomment.  Python is 
>easy to read and easy to write.  I don't think we should be catering to 
>grandma here, but rather to people who know how to run cgi scripts.  If 
>they know that, then they can edit config.py.
>
I think config.py alone is good enough too, I just keep the INI stuff 
just for legacy sake. It was originally there because I got fed up of 
editing different copies of pyblosxom.cgi, one for distribution and one 
for my use. I've seperated the config stuff, but still keep the INI for 
those users using it. Really, it's something we can ignore, I just have 
to make sure that I updated in for those py[] variables that must be there.

>>Nah, too messy to configure by the user, drop-in a plugin when the users
>>needs it should be alright. If the plugin need specific configuration,
>>so be it, document it about needing it in the ini or config.py
>>    
>>
>My issue here is that the user gets a bunch of plugins and now has to 
>delete the ones from the directory that they don't want running.  In 
>retrospect I think the system we chose is probably not a good one.
>  
>
I'm not saying delete the ones you don't need, but put in what you want 
from a source of compatible plugins like what you get in 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pyblosxom/pyblosxom/contrib/plugins/ 
where there is a list of plugins some user may want, but not others, 
copy what you need to libs/plugins/

Of course pyblosxom.cron would need to have it's own plugins and 
contrib/plugins type of directories. This is much easier than modifying 
api.py or config.py for whatever plugins you want to opt in.

>On the flip side, I don't really care a whole lot either way.  I think 
>it's inevitable that we're going to get a vocal user who will complain 
>about it because it's not the best way to do things.
>  
>
:)  No matter how you try to please them, vocal users will be vocal, no 
matter what tool we're using.

>Mmm...  What is our target audience(s)?  What are the knowledge
>requirements we're expecting someone to have in order to:
>  a) install pyblosxom
>  b) use pyblosxom
>  
>
Right now the user base for pyblosxom is users that understand python I 
think. Those who don't know python will probably not use pyblosxom as 
they might not get pyblosxom libraries to byte compile, thus slowing 
down the whole thing. These people should try out the super fast PHP 
blosxom kind, or the kind of cool perl blosxom :) pyblosxom blog have 
more features than I can list (I probably should set up a page listing 
them).

I do expect the users to know what they are getting into installing a 
blosxom type blog engine, as blosxom is no man's land when you compare 
it with, say, MT :)

I just wanted a weblog for work (and now a replacement for my main weblog).

Re: [Pyblosxom-devel] category listings

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

will wrote:

>Actually, that bit about plugins can't do anything with the
>contents--that's not true.  Before anything gets printed out, it goes
>through an executeTransform call in printTemplate.  So every plugin can
>adjust the contents of a given entry if it registers with the parseitem 
>callback chain.
>
Ah, I forgot about that at the moment of writing this, ignore my ramble 
:)  But I did have something I wanted to do that sort of replace 
tools.Walk(). I'm not sure, but I think it's got to do with the entry 
abstraction that Abe was talking about (he's on holidays now though), 
but yeah, once that happens, tools.Walk will only happen in blosxom type 
entries.

>That's what I implemented when I did the pyfortune plugin.  I think you 
>had some issues with it, but it hasn't been removed yet.
>  
>
The only issue was the dynamic stuff that pyfortune created, but there 
is a use for this type too, like I mentioned before, the acronym 
expansion.. I need to get out of my butt and create something with this.

Re: [Pyblosxom-devel] New entry triggered events.

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

On Mon, 27 Jan 2003, Wari Wahab wrote:
> > I'm not sure yet.  In my opinion, we don't have to worry about the 
> > overhead of setting everything up when pyblosxom.cron runs.  So it can 
> > kick off and load every plugin--it doesn't really matter since we don't 
> > need to keep the total runtime to a minimum like we do with pyblosxom.cgi.
> 
> Yup true, I just want to how how plugins can register themselves.

It'd be the same system we have now with pyblosxom.cgi.  You drop the
plugin in the directory.  When pyblosxom.cron kicks off, it imports all
the modules in that directory and does the initialize/load thing and the
plugins register themselves with callback chains in the api module.

Or alternatively, we could provide excplicit plugin importing via the 
config.py or ini files.  I'm actually thinking we should do that instead 
of dropping them in the directory.  Currently there's no way to have a 
module in the directory and not have it loaded.  I think it would be 
better to have an opt-in approach rather than an opt-out approach.

Also, I'm thinking that we're better off with just one configuration file 
instead of two.  Then we can provide verbose directions about how to 
adjust the configuration and what to comment and uncomment.  Python is 
easy to read and easy to write.  I don't think we should be catering to 
grandma here, but rather to people who know how to run cgi scripts.  If 
they know that, then they can edit config.py.

 
> This is pretty much true. pyblosxom.cron needs a name and it's own
> plugins directory :) Hehe, I'm not imaginative enough to name
> pyblosxom.cron though :) The thing is, it should not just be a program
> for cron (some people don't have access to those) it should be able to
> be invoked on the command line or via CGI, yes it can register every
> plugins, and it should be very verbose about it too, so that users can
> see some 'action'.

I'm calling it pyblosxom.cron because that's we want to build a script
that does scheduled maintenance on the pyblosxom system which will most
likely kick off at a certain time of day.  It's just a script--people can
kick it off however they want.


> Nah, too messy to configure by the user, drop-in a plugin when the users
> needs it should be alright. If the plugin need specific configuration,
> so be it, document it about needing it in the ini or config.py

My issue here is that the user gets a bunch of plugins and now has to 
delete the ones from the directory that they don't want running.  In 
retrospect I think the system we chose is probably not a good one.

On the flip side, I don't really care a whole lot either way.  I think 
it's inevitable that we're going to get a vocal user who will complain 
about it because it's not the best way to do things.

 
> > We could do this in the ini file (I think--I actually have no
> > experience with ConfigParser stuff yet) or in config.py.  Whatever we
> > do, we should centralize the configurations for xmlrpc, pyblosxom.cgi,
> > and pyblosxom.cron so we're not sending people hither tither
> > configuring this.
> 
> The INI will replace some of the py.dict variables when it's available,
> it's for people who won't like to meddle around with python stuff
> (except for things like shebang and paths)

Mmm...  What is our target audience(s)?  What are the knowledge
requirements we're expecting someone to have in order to:

  a) install pyblosxom
  b) use pyblosxom

/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] category listings

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

On Mon, 27 Jan 2003, Wari Wahab wrote:
> > In regards to ignoring things globally, I would think that there are a
> > series of directories (and files) that would want to be ignored by
> > everything--regardless of the template.  So then maybe we shoudl add
> > something like this to the ini file:
> >   ignore = CVS *.tmp
> > and then tools.Walk would naturally never return those kinds of files.
> 
> You know, the more I see tools.Walk, the more I agree to myself that we
> shouldn't use it. A better way is to have an entry object of some sort,
> pass it some parameters when we instantiate it, and it fills itself up
> with entry dicts and have methods like getBody or something so that
> plugins can use it, the entry object should also probably know about
> it's 'neighbours' like the comments for example. I don't know how that
> can happen though. Right now, plugins can't do anything with the
> contents. This means changing pyblosxom's architecture, and related
> plugins. I need to think about how to get this done.

Actually, that bit about plugins can't do anything with the
contents--that's not true.  Before anything gets printed out, it goes
through an executeTransform call in printTemplate.  So every plugin can
adjust the contents of a given entry if it registers with the parseitem 
callback chain.

That's what I implemented when I did the pyfortune plugin.  I think you 
had some issues with it, but it hasn't been removed yet.

/will

RE: [Pyblosxom-devel] Re: Item number 5.

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

You guys can just call me Ted ;-).

I'm happy if someone else wants to take a crack at comments.  I just got
sucked up into two weeks of client engagements / travelling, so I'm not
going to be doing much on pyblosxom until Feb 10...

Ted

> -----Original Message-----
> From: pyb...@li...=20
> [mailto:pyb...@li...] On=20
> Behalf Of Wari Wahab
> Sent: Sunday, January 26, 2003 7:10 PM
> To: Blake Winton
> Cc: pyb...@li...;=20
> pyb...@li...
> Subject: [Pyblosxom-devel] Re: Item number 5.
>=20
>=20
> * Blake Winton <bl...@ph...> [030125 02:01]:
> > Comments.  I've been aching for comments on my pyblosxom=20
> site as well,=20
> > and so I've decided to start working on this, if you=20
> haven't already=20
> > started on it.
>=20
> Theodore is working on comments, I suggest you join the=20
> pyblosxom-devel mailing list and share your ideas with all of us.
>=20
> > My first thought is to just store the comments for foo.txt=20
> in a file=20
> > in the same directory named foo.cmt, but I'm not sure how to tell=20
> > pyblosxom to display those.
>=20
> I wanted to do that as well, but it's not scalable at all, don't do it
> :)
>=20
> > Also, I'd love to get trackbacks working for my site, but I have no=20
> > idea what they are, or how to get them working.
>=20
> Trackbacks are comments like animal, see:=20
> http://roughingit.subtlehints.net/pyblosxom/coolStuff/isthispo
ssible.html

and click on the TB+ to see it working in action :)

> Some documentation would be great, but I guess that's the beauty of=20
> Open Source projects, right?  ;)  (Just to check, they aren't=20
> integrated into pyblosxom, so I'll have to use another cgi-script to=20
> get them working?

See http://roughingit.subtlehints.net/pyblosxom/weblogs/tools/tutorial
on how to work trackback with the external Standalone Trackback utility, =
you
must read the documentation of the standalone trackback tool on how to
construct the URL, or view source on my site to see how I do things.

> And do they automatically ping other entries, or is that something=20
> I'ld have to set up as well?)

Auto pings, thanks to Sam Ruby is easily done (albeit seperate from
pyblosxom) Documentation quickie here:
http://roughingit.subtlehints.net/pyblosxom/development/autoping.html

--=20
Regards: Wari Wahab
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/
vim: syntax=3Dmail tw=3D72



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com =
_______________________________________________
Pyblosxom-devel mailing list Pyb...@li...
https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] category listings

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

* will <wi...@bl...> [030127 13:49]:
> > This is a limitation that should be addressed by a template (it's
> > the template problem domain). But the only thing is that blosxom
> > templates are not that powerful to do such things.
> Mmmm...  Perhaps we should have template entries in the ini file that
> dictate properties for those templates?

Too many places to do things, I was thinking of something like
feature.flavour files that override certain pyblosxom variables.

A feature.index (for example in my indexes) could contain things like:

num_entries all
foo bar
etc etc
blog_title My Little Foo Blog :)

Let me think about this, and see how useful can this be.

> In regards to ignoring things globally, I would think that there are a
> series of directories (and files) that would want to be ignored by
> everything--regardless of the template.  So then maybe we shoudl add
> something like this to the ini file:
>   ignore = CVS *.tmp
> and then tools.Walk would naturally never return those kinds of files.

You know, the more I see tools.Walk, the more I agree to myself that we
shouldn't use it. A better way is to have an entry object of some sort,
pass it some parameters when we instantiate it, and it fills itself up
with entry dicts and have methods like getBody or something so that
plugins can use it, the entry object should also probably know about
it's 'neighbours' like the comments for example. I don't know how that
can happen though. Right now, plugins can't do anything with the
contents. This means changing pyblosxom's architecture, and related
plugins. I need to think about how to get this done.

> ps.  I didn't notice I was doing a reply-all on all of the previous
> emails until just now.  My apologies to those who just got duplicates
> and triplicates of some of them.

I have a remove duplicate script in my procmail, so it's okay by me, but
how would you know if someone is or is not in the mailing lists (ok,
this list for now is just you me and Theodore :)

-- 
Regards: Wari Wahab
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/
vim: syntax=mail tw=72

Re: [Pyblosxom-devel] New entry triggered events.

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

* will <wi...@bl...> [030127 13:44]:
> I'm not sure yet.  In my opinion, we don't have to worry about the 
> overhead of setting everything up when pyblosxom.cron runs.  So it can 
> kick off and load every plugin--it doesn't really matter since we don't 
> need to keep the total runtime to a minimum like we do with pyblosxom.cgi.

Yup true, I just want to how how plugins can register themselves.

> However, assume we have a bunch of pyblosxom.cron specific plugins--we 
> don't want pyblosxom.cgi to load them all every time it kicks off.

This is pretty much true. pyblosxom.cron needs a name and it's own
plugins directory :) Hehe, I'm not imaginative enough to name
pyblosxom.cron though :) The thing is, it should not just be a program
for cron (some people don't have access to those) it should be able to
be invoked on the command line or via CGI, yes it can register every
plugins, and it should be very verbose about it too, so that users can
see some 'action'.

> I'm thinking we might want to re-architect things, but I'm not sure
> what's the easy/nice approach to do it.  Seems to me that we should
> have in the config file a list of the modules that should get loaded
> and only load those rather than our current setup where we load
> anything in the directory.

Nah, too messy to configure by the user, drop-in a plugin when the users
needs it should be alright. If the plugin need specific configuration,
so be it, document it about needing it in the ini or config.py

> If we do that, then both pyblosxom.cgi and pyblosxom.cron can have the
> same system because we're not incurring the overhead involved in
> setting up things we're not going to use in pyblosxom.cgi when
> pyblosxom.cgi kicks off.

Yup.

> We could do this in the ini file (I think--I actually have no
> experience with ConfigParser stuff yet) or in config.py.  Whatever we
> do, we should centralize the configurations for xmlrpc, pyblosxom.cgi,
> and pyblosxom.cron so we're not sending people hither tither
> configuring this.

The INI will replace some of the py.dict variables when it's available,
it's for people who won't like to meddle around with python stuff
(except for things like shebang and paths)

-- 
Regards: Wari Wahab
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/
vim: syntax=mail tw=72

Re: [Pyblosxom-devel] category listings

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

On Mon, 27 Jan 2003, Wari Wahab wrote:
> 
> > I don't know how we want to handle ignoring certaing directories in
> > pyblosxom.  I would think this is the sort of thing we want to do
> > globally somehow.  Maybe tools.Walk should know about ignored
> > directories and not recurse through them?
> 
> This is a limitation that should be addressed by a template (it's the
> template problem domain). But the only thing is that blosxom templates
> are not that powerful to do such things.

Mmmm...  Perhaps we should have template entries in the ini file that
dictate properties for those templates?

In regards to ignoring things globally, I would think that there are a
series of directories (and files) that would want to be ignored by
everything--regardless of the template.  So then maybe we shoudl add
something like this to the ini file:

  ignore = CVS *.tmp

and then tools.Walk would naturally never return those kinds of files.

/will

ps.  I didn't notice I was doing a reply-all on all of the previous 
emails until just now.  My apologies to those who just got duplicates and 
triplicates of some of them.

Re: [Pyblosxom-devel] New entry triggered events.

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

On Mon, 27 Jan 2003, Wari Wahab wrote:
> > 
> >  1. kick off and read the ini file to configure itself
> >  2. instantiate its plugins
> >  3. get a full entry_list of all the entries
> >  4. generate a list of differences between the two lists (which
> >     will be changes since the last run)
> >  5. kick off some handler for plugins to do their thing
> 
> How would you do 2. and 5.? Sound's different from the plugins in
> pyblosxom right now :)

I'm not sure yet.  In my opinion, we don't have to worry about the 
overhead of setting everything up when pyblosxom.cron runs.  So it can 
kick off and load every plugin--it doesn't really matter since we don't 
need to keep the total runtime to a minimum like we do with pyblosxom.cgi.

However, assume we have a bunch of pyblosxom.cron specific plugins--we 
don't want pyblosxom.cgi to load them all every time it kicks off.

I'm thinking we might want to re-architect things, but I'm not sure what's 
the easy/nice approach to do it.  Seems to me that we should have in the 
config file a list of the modules that should get loaded and only load 
those rather than our current setup where we load anything in the 
directory.

If we do that, then both pyblosxom.cgi and pyblosxom.cron can have the 
same system because we're not incurring the overhead involved in setting 
up things we're not going to use in pyblosxom.cgi when pyblosxom.cgi kicks 
off.

We could do this in the ini file (I think--I actually have no experience
with ConfigParser stuff yet) or in config.py.  Whatever we do, we should
centralize the configurations for xmlrpc, pyblosxom.cgi, and
pyblosxom.cron so we're not sending people hither tither configuring this.

/will


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

[Pyblosxom-devel] Re: Item number 5.

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

* Blake Winton <bl...@ph...> [030125 02:01]:
> Comments.  I've been aching for comments on my pyblosxom site as well,
> and so I've decided to start working on this, if you haven't already
> started on it.

Theodore is working on comments, I suggest you join the pyblosxom-devel
mailing list and share your ideas with all of us.

> My first thought is to just store the comments for foo.txt in a file
> in the same directory named foo.cmt, but I'm not sure how to tell
> pyblosxom to display those.  

I wanted to do that as well, but it's not scalable at all, don't do it
:)

> Also, I'd love to get trackbacks working for my site, but I have no
> idea what they are, or how to get them working.  

Trackbacks are comments like animal, see:
http://roughingit.subtlehints.net/pyblosxom/coolStuff/isthispossible.html

and click on the TB+ to see it working in action :)

> Some documentation would be great, but I guess that's the beauty of
> Open Source projects, right?  ;)  (Just to check, they aren't
> integrated into pyblosxom, so I'll have to use another cgi-script to
> get them working?  

See http://roughingit.subtlehints.net/pyblosxom/weblogs/tools/tutorial
on how to work trackback with the external Standalone Trackback utility,
you must read the documentation of the standalone trackback tool on how
to construct the URL, or view source on my site to see how I do things.

> And do they automatically ping other entries, or is that something
> I'ld have to set up as well?)

Auto pings, thanks to Sam Ruby is easily done (albeit seperate from
pyblosxom) Documentation quickie here:
http://roughingit.subtlehints.net/pyblosxom/development/autoping.html

-- 
Regards: Wari Wahab
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/
vim: syntax=mail tw=72

Re: [Pyblosxom-devel] New entry triggered events.

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

* will <wi...@bl...> [030126 01:00]:
> I'd probably make this a completely separate script from
> pyblosxom.cgi--I can't tell if that's what you're implying or not.  It
> would use the same ini file to figure out pyblosxom settings, but have
> a different plugins directory to limit unneeded overhead of
> initializing plugins that aren't needed.  So then it's run-time
> algorithm would look like this:
> 
>  1. kick off and read the ini file to configure itself
>  2. instantiate its plugins
>  3. get a full entry_list of all the entries
>  4. generate a list of differences between the two lists (which
>     will be changes since the last run)
>  5. kick off some handler for plugins to do their thing

Yes sir, this is how I envisioned the script to work, it's gotta be
seperate, a queue don't make sense cause you have to browse your site
everytime you want something to happen. If it's seperate and runs from
cron, entries scp'ed to blosxom's directory or using xmlrpc would work
as expected.

I can do a simple walk, store it in a db, and a later run would 'notice'
the changes if any. Simple actually.

How would you do 2. and 5.? Sound's different from the plugins in
pyblosxom right now :)

I was thinking of doing the plugins like the load() mechanism, which
would mean 1, 3, 4, 5, I think.

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

Re: [Pyblosxom-devel] category listings

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

* will <wi...@bl...> [030126 04:49]:
> There's already a max config parameter.  I'm wondering if we shouldn't
> have an override via the url.

Yeah, that max parameter is called num_entries in py dict.

> I don't know how we want to handle ignoring certaing directories in
> pyblosxom.  I would think this is the sort of thing we want to do
> globally somehow.  Maybe tools.Walk should know about ignored
> directories and not recurse through them?

This is a limitation that should be addressed by a template (it's the
template problem domain). But the only thing is that blosxom templates
are not that powerful to do such things.

Why templates, well if you expect a large number of entries, you will
need to do an index template, for an index template, it'll be light on
the bandwidth.

Another thing we could consider is to have a <prev and a next> page
thingy. First time you'll see an entry overflow, you'll have something
like pyblosxom.cgi/category?page=n, which then causes pyblosxom to
display (num_entries * n) to (num_entries * n + (num_entries - 1))

What do you think? Of course, this would need a page plugin thingy that
takes in an entryList, and modifies it to display the proper entries.

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

Re: [Pyblosxom-devel] category listings

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

* will <wi...@bl...> [030126 00:37]:
> good thing to add a max override on the url like the flavour.
> Something like this:
>    http://www.bluesock.org/~willg/cgi-bin/pyblosxom.cgi/dev?max=26

For things like this, I think a file in a directory could do an override
(not hard to do), also I guess it makes more sense if a template can
override it (how?) Like the index template, which should allow for all
entries.

> In this case, we would show 26 entries.  Would that be a good idea, or
> not?  My concern is that old entries won't be viewable if we spill
> over the max.  Of course, I guess it prevents people from pulling
> _all_ your entries.  I don't know if that's good or bad, though.  

Yes I know, how annoying indeed. The max=xxx is a good idea for short
term. There has got to be another way though.

> How do other *blosxom things handle this?

The buggy behaviour you see happens in blosxom as well I think. But it's
also a feature :)

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

[Pyblosxom-devel] Re: [Pyblosxom-checkins] pyblosxom/libs/plugins pycategories.py,1.2,1.3

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

* wil...@us... <wil...@us...> [030126 00:34]:
> Another thing to note is that when you click on a category, you may
> not see all the entries for that category--it depends on whether it
> spills over the entry max, I think.

I guess, this is a bug :( But I also think that blosxom is designed that
way.

http://roughingit.subtlehints.net/pyblosxom/weblogs?flav=index should
contain 39 entries not ten.

But then, if you don't have a limit, you'll have a problem of people
getting your page that's full of entries.

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

RE: [Pyblosxom-devel] category listings

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

There's already a max config parameter.  I'm wondering if we shouldn't 
have an override via the url.

I don't know how we want to handle ignoring certaing directories in
pyblosxom.  I would think this is the sort of thing we want to do globally
somehow.  Maybe tools.Walk should know about ignored directories and not
recurse through them?

/will


On Sat, 25 Jan 2003, Theodore W. Leung wrote:

> A max seems like a good idea -- the question is is it a form argument or a
> config parameter.
> Also, I hacked my local copy of pycategories.py to test whether there are
> CVS directories present.  I'm version controlling my data directory, so that
> I can check out a copy on my laptop and blog disconnected.
> 
> Ted
> 
> > -----Original Message-----
> > From: pyb...@li... 
> > [mailto:pyb...@li...] On Behalf Of will
> > Sent: Saturday, January 25, 2003 8:40 AM
> > To: pyb...@li...
> > Subject: [Pyblosxom-devel] category listings
> > 
> > 
> > 
> > I fixed up categories so it's all pretty now.  When doing 
> > that I noticed 
> > that if you browse by category, you only get the max number 
> > of entries as 
> > specified in the ini file.  I was wondering if it'd be a good 
> > thing to add 
> > a max override on the url like the flavour.  Something like this:
> > 
>    http://www.bluesock.org/~willg/cgi-bin/pyblosxom.cgi/dev?max=26
> 
> In this case, we would show 26 entries.  Would that be a good idea, or 
> not?  My concern is that old entries won't be viewable if we spill over 
> the max.  Of course, I guess it prevents people from pulling _all_ your 
> entries.  I don't know if that's good or bad, though.  How do other 
> *blosxom things handle this?
> 
> /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] New entry triggered events.

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

I think we could write a quickie script that goes through your root to see 
if there are new entries since the last run and if there are, then it 
rebuilds the cached pages.  Then you could dump this script in cron to 
kick off every, say, hour.  That'd be pretty safe.

I'd probably make this a completely separate script from pyblosxom.cgi--I
can't tell if that's what you're implying or not.  It would use the same
ini file to figure out pyblosxom settings, but have a different plugins
directory to limit unneeded overhead of initializing plugins that aren't
needed.  So then it's run-time algorithm would look like this:

 1. kick off and read the ini file to configure itself
 2. instantiate its plugins
 3. get a full entry_list of all the entries
 4. generate a list of differences between the two lists (which
    will be changes since the last run)
 5. kick off some handler for plugins to do their thing


Alternatively, we could have pyblosxom.cgi and whatever other things we
have (xmlrpc blogging, email blogging, ...) dump things in a queue and
then this separate script would execute on tasks in the queue.  That's how
Mailman used to work.  It's not too hard to setup.  I'm not sure how much 
better it would be than having this new script figure things out on its 
own.  Probably not wildly exciting either way.

I like this solution.  I think the problem with *blosxom is that it only 
handles reading entries from the root--it doesn't really define the 
content creation mechanism, so content could come from anywhere (xmlrpc, 
email, editing entries by hand...) and that causes us to have to figure 
things out after the fact rather than when they're created on the spot.

So I guess my addition to this train of thought is that this should be a 
separate script with a separate plugins directory.  Maybe call them 
pyblosxom.cgi and pyblosxom.cron with a cronplugins/ directory?

/will


On Thu, 23 Jan 2003, Wari Wahab wrote:
> 
> As some of you know, I was thinking of doing plugins that will touch a 
> makeshift db to tell a cronjob what to do later. Don't listen to me, it 
> wasn't me putting on my unix administrator cap :) This should not be a 
> job of pyblosxom.
> 
> I mean, why get pyblosxom to notice when a cronjob can do the noticing. 
> What the program in your control, make it a command line program, cannot 
> access the command line, allow web access to it, with a password or 
> something.
> 
> A little python script can be a cgi, a command line program and a 
> cronjob (to run quietly). Actually it does not have to be a python 
> script but where's the fun in that? :) Using plugins similar to Will's 
> load() style plugin, I will pass an object containing py config 
> variables, as well as a list of what blogs changed or is new to 
> pyblosxom. The plugins then do what they need to do.
> 
> What are the areas the plugins can help? Off the hat, I can think of,
> 1. static page renders,
> 2. pingbacks,
> 3. trackbacks or
> 4. what ever feedbacks that needs to be 'activated' on new entries.
> 5. Weblogs.com and blo.gs ping, or wherever users might want to ping to 
> notify a new blog entry.
> 6. external uploads to webservers (blog locally, publish globally)
> 7. Backups
> 8. Web site cleanups
> 
> My hat's empty now :)
> 
> You can see how useful this can be, and I have not even started on 
> anything yet :)
> 
> So what do you think? Do I sound like rambling? :) Is this a good idea, 
> or something I should scrap? Do you have task ideas out off your hats?
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
> 

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