Re: [siesta-dev] road to a release

[prev] [thread] [next] [lurker] [Date index for 2002/09/10]

From: Richard Clamp
Subject: Re: [siesta-dev] road to a release
Date: 21:05 on 10 Sep 2002
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:

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


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

Generated at 13:56 on 01 Jul 2004 by mariachi 0.52