[prev] [thread] [next] [lurker] [Date index for 2002/09/15]
On Sun, Sep 15, 2002 at 09:00:32AM +0100, Simon Wistow wrote: > On Sat, Sep 14, 2002 at 11:17:42PM +0100, Richard Clamp said: > > Also nacho and tequila need real manpages, > > even if they just refer to Siesta::UserGuide. > > How do you mean? Proper man pages as in 'well formed' or proper man > pages as in 'more like the stuff that's in doc/MANUAL'? Speaking of > which - any clever ideas about how doc/MANUAL could be autoturned into > pod on install? "real manpages, even if they just refer to Siesta::...". Definitely well-formed, and probably very thin references into the main docs. It'll involve translating doc/MANUAL into .pod manually, and then these manpages point at that one. lib/Siesta/Guide.pod is my current best hunch for a name, then users will be able to type C<man Siesta::Guide> post-install. > > Installing stuff. I see there have been some docs going in that > > explain what the installation routines don't do for you. This strikes > > me as patching in the wrong direction. > > I was just kind of documenting what I had to do to get it working which > was quicker than trying to write something that worked out what the mail > and http users were and then making a new group and adding those users > to that new group. And it was better than nothing at all. I agree, I don't think we should be creating groups at all, but that's not even the part of the docs I'm gesturing at. -install the database in. /usr/local/siesta/ will probably be ok. +install the database in. /usr/local/siesta/ will probably be ok. The +installation process doens't create directory for you so you may need to +do that. Plus also you're putting a lot of documentation in assumes usage of SQLite. Anyone using a different storage backend, or even a different RDBMS, will be most confused that the install path is "where the database lives". > > Siesta::Storage::DBI - works well enough, but there's entirely too > > much duplicated code, and the config stuff that lives there is still > > too clever. > > s/clever/not well documented enough/ ? > > It's not really that complicated. If it's passed both a user and a list > then it looks up the config value for per-user, per-list. If that's not > found then it trys per-user, then per-list and then default. > > Only passed a list? Then try per-list and then default. Only a user? > Per-user then default. Even if those rules were simple (they're not), they still don't belong in the Storage layer, which is meant to be a *thin* shim over the backend storage. > > Siesta::Send::*->process. Um, process seems like the wrong verb. > > How does C<send> sound? > > Sure. I just used C<process> to be consistent with Plugin.pm and > Siesta.pm I think you're reading that consistency inside out. Siesta processes requests. Plugins process plugin stages in the pipeline. They're consistent with what they do. That they have the same name is more coincidence than some guiding principle of calling the main functional method process. > > Test coverage sucks as > > Really? I thought that the last time you did a coverage (I can't here, I > don't have 5.6.1) test it actually covered quite a lot. Of the things that it covers we get about 67% statement coverage and absolutely piss poor branch and conditional coverage. This is only testing a very small cross-section of the code too, thus leading to it generally sucking ass. -- Richard Clamp <richardc@xxxxxxxxx.xxx>There's stuff above here
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52