Storage and Deferring (was Re: [siesta-dev] tiny refactor thoughts)

[prev] [thread] [next] [lurker] [Date index for 2003/04/01]

From: Richard Clamp
Subject: Storage and Deferring (was Re: [siesta-dev] tiny refactor thoughts)
Date: 12:14 on 01 Apr 2003
On Tue, Apr 01, 2003 at 03:00:51AM +0100, Simon Wistow wrote:
> On Mon, Mar 31, 2003 at 05:59:23PM +0100, Richard Clamp said:
> > Now I'm starting to think I'm just talking to myself here, but here's
> > another little one.
> 
> Au contraire.
> 
> I've been thinking about arbitary stashes. Sometimes a key=value schema 
> isn't enough for a plugin (for example the subscribe plugin could do 
> with having a timestamp associated to expire subscription attempts) so 

Um, only in your old model for subscription attempts.

I'll now attempt to show you a simpler way, with the caveat that I
need to finish the defer stuff that I half-did the other week.

Subscribe {
   my $self = shift;
   my $message = shift;

   my $list = $self->list;
   my $siesta = $list->siesta;

   my $new_message = 'From: $sender\nTo: foo-request\n\nsubscribe $list->name\n";
   $siesta->process( mail => $new_message, list => $list, action => 'request' );
}

Then, Request is written like:

Request {
   my $self = shift;
   my $message = shift;

   if ($messgae =~ /confirm $id/) {
     my $actions = $list->get_deferred($id);
     # do the actions
     ...
     return;
   }
   $message->defer( for => confirm );
   $message->reply( 'you're going to have to confirm that' );
}

To finish:

CREATE TABLE defer (
    id ...,
    for ..., # who can unlock this from the defer queue
    why ..., # why it's in the queue/where to put it when it's unlocked
    delete_after ..., # so yes, I just added it
    message TEXT
)

And make the defer methods work against that.

Though complex, I think it's already sharable between Request and
MembersOnly, so the web interface can approve non-member posts
etc. without over-coding.

> I was wondering how to achieve something more substantial. Pixie would 
> be good ... if it didn't require 5.8. Data::Denter? YAML (I've also 
> thought of a YAML Storage backend).

A YAML storage backend could be quite cool, apart from then we
magically get all of the locking/permissions pains back that we used
to have with SQLite before I moved this install over to mysql.
 
> Do we really need it? Is it going to be confusing?

I think No and Yes, respectively.

-- 
Richard Clamp <richardc@xxxxxxxxx.xxx>
There's stuff above here

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