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.