[prev] [thread] [next] [lurker] [Date index for 2002/09/10]
On Tue, Sep 10, 2002 at 06:56:30PM +0100, Simon Wistow wrote: > ... or at least an announcement. > > I'm not sure if this a verboten subject or something but - what needs to > be done to do an initial release? > > The only major thing I can think of after today's checkins is the > initial installation of the database and maybe creation of a siesta user > or something for security reasons or summat. And ensuring that subscriptions can happen from the wire. > We have complete configuration via nacho, Then t/05setup_database.t needs to be rewritten in terms of it. > we have installation > documentation, we have fairly comprehensive tests (I need to do tests > for the plugin order stuff I've done today) I think the plugin order stuff is fucked. Certainly I'd expect ID to be a unique column with a sequence on it and so specifying explicit values into it will just lead to badness. An extra "order" column is probably called for, and since we're no longer doing things with Class::DBI we don't actually need that id field, so we may as well just rename it. > which we could do with > running through Devel::Cover. cvs update ; perl Makefile.PL ; make ; make cover I have to figure out why it doesn't give coverage numbers for the Siesta::Storage::* files, they seem perversely absent: http://mirth.unixbeard.net/~richardc/cover_db/cover_db.html > I need to add some plugin ordering methods > to the list object (I'll do that tomorrow) and > do we need to do that > hack to allow SQLite to cope with simultaneous connections? Done. > Oh, and I > had an idea about the mail object having a send method which would, in > turn call Siesta::send (or Siesta::Send::send or something) which would > make replys and bounces easy. Plus you could subclass with Sendmail.pm > SMTP.pm or whatever and then do an equivalent of Siesta->connect like > Siesta->send. I don't follow. Replys and bounces aren't actually hard, and instead of subclassing you could just supply a new Plugin, so I don't see quite where you're going with this. > Ideas, thoughts, comments? I need to take a proper walk through all the code/tests before I even sync CVS out onto plough, as I'm now not terribly confident that it will just work. From a quick tour I took earlier, I think Siesta::Storage::DBI has entirely too much logic in it now, as well as a chunk of fugly code duplication, thoughts on this later. -- Richard Clamp <richardc@xxxxxxxxx.xxx>
Generated at 13:56 on 01 Jul 2004 by mariachi 0.52