14:14:09 <so_solid_moo> #startmeeting 0.7.0 planning meeting
14:14:17 <so_solid_moo> #chair so_solid_moo fatpelt_laptop
14:14:33 <so_solid_moo> #topic Review of 0.6
14:14:43 <so_solid_moo> So.. is everyone running 0.6 now? :D
14:14:50 <fatpelt_laptop> #agreed
14:15:12 <fatpelt_laptop> i was looking into one possible bug last night but i failed to reproduce it.
14:15:22 <fatpelt_laptop> i'm thinking it'll go away with the new queue
14:15:29 <so_solid_moo> jur still has issues
14:15:36 <fatpelt_laptop> ??
14:15:37 <so_solid_moo> he has the "keeps sending mails" problem
14:15:44 <fatpelt_laptop> oh
14:15:46 <so_solid_moo> which was previously associated with large attachments
14:16:03 <so_solid_moo> again, I suspect queue work would render than gone
14:16:18 <so_solid_moo> he also has that pirate party / tls thing which I think we talked about hostname being responsible for?
14:17:19 <fatpelt_laptop> i think the hostname is the cause yeah.  i think that's why there aren't other packages that set up tls on install and require a lot of manual intervention
14:17:36 <so_solid_moo> I'm kind of torn in multiple directions over this one
14:17:42 <so_solid_moo> I don't like the idea of setting up non-tls by default
14:17:49 <so_solid_moo> but also, if we can't get it right, then it's not worth doing
14:17:56 <fatpelt_laptop> #agreed
14:18:28 <fatpelt_laptop> perhaps change the install process to be a bit more clear?  "use the hostname that the Internet will see as the ptr" or something like that?
14:18:30 <so_solid_moo> you realise by doing that our logs will have empty agreements?
14:18:31 <so_solid_moo> :D
14:18:57 <fatpelt_laptop> hehe
14:19:14 <fatpelt_laptop> #agreed, pelt still hasn't fully booted this morning
14:19:24 <so_solid_moo> so maybe our install process should essentially be 'put files in place, write out some basic directories, and only bring up the configuration bits'
14:19:35 <so_solid_moo> and make the user properly configure the system first
14:20:18 <fatpelt_laptop> what do you mean?  it is mostly properly configured now other than the hostname portion isn't it?
14:20:31 <so_solid_moo> well, kinda
14:20:39 <so_solid_moo> the hosted domains entry thing is a bit clumsy and basic
14:21:07 <so_solid_moo> e.g., the email -> user mapping may or may not be correct until you configure it further
14:21:20 <fatpelt_laptop> ah yeah.  that is definately the case
14:21:52 <so_solid_moo> I'm wondering if we ought to kick the user into the web configure or something before bringing up the system fully
14:22:27 <fatpelt_laptop> that sounds like a good idea, except for the fact that we dont' have one yet :D  but that's a planned part of .7
14:22:54 <so_solid_moo> well, indeed
14:23:11 <so_solid_moo> it would mean that bongo-config install could be much simpler and/or die
14:24:07 <fatpelt_laptop> i think we need to keep some of the functionality.  add user etc.  we'll want it to make ourselves a bit easier to script if needed
14:24:11 <fatpelt_laptop> (eg:  migrations)
14:24:57 <so_solid_moo> hm
14:25:15 <so_solid_moo> and there's also setting up another host for a 'cluster'
14:25:42 <fatpelt_laptop> we were still thinking a single store with multiple bongo-manager's right?
14:25:42 <so_solid_moo> perhaps we should attempt to write up how the install / configuration should work for the various use cases and then decide what lives and dies?
14:25:46 <so_solid_moo> yeah, right
14:27:06 <fatpelt_laptop> 1)  single system 2) single system with vhosts 3) multiple systems 4) multiple systems with vhosts  ?
14:27:19 <so_solid_moo> what are vhosts?
14:27:45 <fatpelt_laptop> basically the non-standard user mapping
14:27:54 <fatpelt_laptop> mappings
14:28:10 <so_solid_moo> I don't think I'd want to make that choice up-front as a configuration option
14:28:27 <so_solid_moo> I don't think you need any option for the first system
14:28:58 <fatpelt_laptop> ok.  so we're just looking at the installation presently
14:29:19 <so_solid_moo> Well. I think installation and configuration could be two different tasks, and the extent to which they should overlap - I'm not sure
14:30:03 <so_solid_moo> like, for the multiple system thing, you never want to configure systems 2/3/... etc.
14:30:05 <fatpelt_laptop> ok.  so then it would seem that the only configuration steps that would overlap would be "where is the store" in the multiple server configuration
14:30:14 <so_solid_moo> you just want to do ./bongo-config add-to-system <ip of store>
14:30:17 <so_solid_moo> or something
14:32:35 <fatpelt_laptop> #agreed  .bongo-config add-to-system sounds like the extent of multi-server configuration bits
14:32:54 <fatpelt_laptop> with that then the single server config goes away
14:33:01 * so_solid_moo is going to have to teach fatpelt_laptop about the meetbot :D
14:33:18 <fatpelt_laptop> um.  what did i do wrong that time?
14:33:27 * fatpelt_laptop hangs his head in shame.
14:33:39 <so_solid_moo> you're supposed to use it to denote actions which have general agreement
14:34:19 <so_solid_moo> so, like, if someone was going to write bongo-config add-to-system, that would be an agreed
14:34:27 <fatpelt_laptop> ah :D
14:34:37 <so_solid_moo> not "#agreed we all like cake" kind of thing :)
14:34:41 * fatpelt_laptop hangs his head in further shame
14:34:54 <fatpelt_laptop> but I DO like cake!  esp angel food
14:34:55 <so_solid_moo> no worries
14:34:57 <so_solid_moo> hehe
14:35:05 <so_solid_moo> I had that for the first time last time I was in the states
14:35:11 <so_solid_moo> tbh, didn't overly like it
14:35:24 <fatpelt_laptop> hehe
14:36:38 <so_solid_moo> but anyway, we're still supposed to be on 0.6
14:36:47 <so_solid_moo> not sure there's much else to say about it though
14:36:50 * fatpelt_laptop proposes to write bongo-config bake-angel-food-cake :p
14:36:56 <so_solid_moo> hehe
14:38:11 <fatpelt_laptop> much about .6 ?
14:38:36 <so_solid_moo> yeah
14:39:05 <fatpelt_laptop> i ran store through valgrind and i think there might be a small mem leak in there somewhere, but i haven't tracked it yet
14:39:23 <so_solid_moo> that wouldn't necessarily surprise me too much, although I'm not sure it will be in the core store code
14:39:25 <fatpelt_laptop> i think another task for .7 is to valgrind everything pretty well and squash as much of that as possible
14:39:47 <so_solid_moo> good plan
14:40:36 <fatpelt_laptop> what is the best way to kill the daemons?  -TERM ?
14:40:57 <so_solid_moo> kill them for what purpose?
14:40:58 <fatpelt_laptop> i usually do a ^c but i'm not sure if that cleans up the same way
14:41:03 <so_solid_moo> oh, right
14:41:08 <so_solid_moo> yeah, TERM is usually best
14:41:14 <fatpelt_laptop> some of the valgrind "isues" are due to poor cleanup
14:41:15 <so_solid_moo> imap isn't very good at listening for that tho
14:41:22 <so_solid_moo> yeah, I know there is some of that in the store
14:41:27 <fatpelt_laptop> i usually have to -KILL that one
14:42:03 <so_solid_moo> #agreed fatpelt will valgrind all of bongo for 0.7 :)
14:42:18 <fatpelt_laptop> and bake-angel-food-cake
14:43:01 <fatpelt_laptop> or snickerdoodles.  both are tasty....
14:43:12 <fatpelt_laptop> i can't think of any other major issues with .6
14:43:33 <so_solid_moo> cool
14:43:41 <so_solid_moo> #topic Goals and general bits for 0.7
14:45:59 <fatpelt_laptop> ah..   i'm seeing now a bit better
14:46:15 <so_solid_moo> :)
14:46:17 <fatpelt_laptop> start w/rules?
14:46:36 <so_solid_moo> sure
14:47:22 <fatpelt_laptop> ok.  we need to come up with a sane way to store user preferences. currently rules are stored in _system:/config/rules/<username>
14:47:41 <fatpelt_laptop> i'm not sure this is the right place.  if it is, we need to get users' rights to their rules
14:48:06 <so_solid_moo> well, we can put it in the user's store, but then we need to give the rules agents rights to that
14:48:17 <so_solid_moo> I would say the easier way is to keep it as-is and just add the right ACLs
14:49:06 <fatpelt_laptop> #agreed so_solid_moo will modify the user create to grant rights to the user's rules document
14:49:21 <fatpelt_laptop> (that wasn't quite right, but i'm getting closer)
14:49:27 <so_solid_moo> near enough :)
14:49:35 <so_solid_moo> except I think it's the config tool which does it rather than the user create
14:50:17 <fatpelt_laptop> but we won't have a user when config runs right?
14:50:53 <so_solid_moo> no, I mean a config tool as in rules UI
14:51:08 <fatpelt_laptop> oh.  ok.  yeah.  that sounds like a good idea
14:51:17 <so_solid_moo> because equally if we had an LDAP backend, we wouldn't see the user create bit
14:51:44 <fatpelt_laptop> very true yeah
14:52:36 <fatpelt_laptop> another change will be that we need to use the right rule format
14:52:58 <so_solid_moo> nice bit o' json? :)
14:52:59 <fatpelt_laptop> i think the rest of rules can stay the same, but we'll need to revisit rules when we chat queue
14:53:05 <fatpelt_laptop> yup
14:53:10 <so_solid_moo> cool
14:53:14 <fatpelt_laptop> i've got the rule format here in a file that i can slexy
14:53:29 <so_solid_moo> #agreed fatpelt to update rules agent config file format
14:53:53 <so_solid_moo> Is there any other agent we need to poke other than those listed on the agenda?
14:54:04 <fatpelt_laptop> http://slexy.org/view/s2HrYrphJY
14:54:49 * fatpelt_laptop checks the agenda
14:55:08 <so_solid_moo> sorry, I should have put it on the wiki
14:56:04 <fatpelt_laptop> heh.  yeah, it's not on the roadmap which was where i went
14:56:30 <so_solid_moo> maybe I can talk Lance or someone into updating that stuff :D
14:57:07 <fatpelt_laptop> can you email the agenda to -dev ?
14:57:40 <so_solid_moo> I did do, didn't I?
14:57:55 <fatpelt_laptop> oh.  let me check
14:58:07 <so_solid_moo> http://slexy.org/view/s203EkUaN6
14:58:09 <fatpelt_laptop> heh.  yup
14:58:32 <fatpelt_laptop> when do we want to re-work smtpd ?
14:58:48 <fatpelt_laptop> that's a fair amount for .7 i think with what's already on the schedule
14:59:07 <so_solid_moo> leave it for 0.7 imho
14:59:20 <so_solid_moo> if we can avoid touching any agents other than to get the queue work done I think that's good
15:00:30 <fatpelt_laptop> ok.  i agree with that, except for rules.  we should definately do that now so that people can actually use it
15:00:35 <so_solid_moo> yeah
15:00:39 <so_solid_moo> and it's a simple job
15:01:40 <fatpelt_laptop> ok.  now for queue
15:01:41 <fatpelt_laptop> ?
15:01:49 <so_solid_moo> yes, why not
15:01:54 <so_solid_moo> #topic Queue work for 0.7
15:02:38 <fatpelt_laptop> the queue i think is going to be a bit of a bear to work.  we need to identify what portions of the queue protocol we need to add to the store protocol.  rules for one uses QSRCH which i don't think we have in store yet
15:02:57 <so_solid_moo> what's qsrch?
15:03:00 <so_solid_moo> :D
15:03:06 <fatpelt_laptop> basically just a grep over the email
15:03:12 <so_solid_moo> oh, right
15:03:26 <fatpelt_laptop> i did try to find a message parser the other night and came up empty.
15:03:41 <so_solid_moo> message parser for what?
15:04:56 <fatpelt_laptop> so that i could do something sane like (in object style pseudo) strcmp(Parser->Header, "") == 0
15:05:26 <fatpelt_laptop> indead of searching for "header: " and then having to worry about new lines and such
15:05:27 <so_solid_moo> the document properties are not enough?
15:05:36 <so_solid_moo> oh, I kinda see
15:06:41 <so_solid_moo> maybe the first thing to do would be to see what stuff queue can do that we're missing?
15:06:41 <fatpelt_laptop> python had a pretty nice rfc822 parser
15:06:52 <so_solid_moo> gmime has an rfc822 parser too :)
15:06:59 <so_solid_moo> we already use it, in fact
15:07:04 <fatpelt_laptop> really?  that could be handy!
15:07:24 <so_solid_moo> if you look at the document properties that are extracted from e-mails, they're all parsed by gmime
15:09:19 <so_solid_moo> like From:, To:, Date:, etc.
15:10:04 <fatpelt_laptop> ok.  cool!
15:10:10 <fatpelt_laptop> for rules we'll need:  <checking>
15:10:57 <fatpelt_laptop> oh.  hte list is a bit long.  rules.c:520
15:11:20 <fatpelt_laptop> we obviously can drop some if needed/wanted
15:11:25 * so_solid_moo looks
15:12:02 <fatpelt_laptop> some of the time ones we might not need
15:12:25 <so_solid_moo> well, most of that data we'll probably have already tbh
15:13:58 <fatpelt_laptop> ok.  so that may not be as bad an issue as i thought
15:13:59 <so_solid_moo> stuff like FREE and things - erk
15:14:13 <so_solid_moo> but yeah, I think probably 80%+ of that we already have
15:14:15 <fatpelt_laptop> that's all for calendaring right?
15:14:19 <so_solid_moo> yeah
15:14:46 <fatpelt_laptop> so we could drop those for .7 if we needed to.  or at least /* do nothing */ them
15:14:55 <so_solid_moo> right
15:15:17 <so_solid_moo> having the store parse out arbitrary headers is probably going to be quite easy
15:15:30 <so_solid_moo> so there probably won't be many we can't do for 0.7
15:16:21 <fatpelt_laptop> i don't think many people will use a lot of those in the beginning.  basically from, to, header, body.  perhaps size
15:16:36 <so_solid_moo> we don't have a body grep but that's easy enough
15:18:54 <fatpelt_laptop> i'm looking down the queue protocol and we'll need most of the commands i think
15:19:49 <so_solid_moo> right, but they won't all need to be specific commands like they are now I don't think?
15:20:00 <so_solid_moo> maybe we should write a queue -> store dictionary... :)
15:20:53 <fatpelt_laptop> heh.  i like that idea yeah.  and i agree that they won't all be like they are now.
15:23:12 <fatpelt_laptop> i don't see any command that'd work for the qstor command
15:23:29 <fatpelt_laptop> unless
15:23:47 <fatpelt_laptop> the agents were smarter and just made a full store document then did a "write"
15:24:13 <so_solid_moo> what does qstor do?
15:25:01 <fatpelt_laptop> basically sets up the envelope file
15:25:17 <fatpelt_laptop> though i think we want that in the future in some form
15:25:32 <so_solid_moo> I'm not sure I see the use of it?
15:26:09 <fatpelt_laptop> currently agents might need the information of those header fields.  if we dont have something like it will we need to parse the email multiple times?
15:26:30 <so_solid_moo> depends on our approach
15:26:37 <so_solid_moo> stuff like to / from /etc. we already cache in the db
15:26:52 <so_solid_moo> I would say all the stuff on the envelope is already a document property
15:27:03 * fatpelt_laptop opens an envelope
15:28:14 <fatpelt_laptop> address flags and date are the only other fields in the standard envelope
15:28:25 <fatpelt_laptop> er...  that's address, flags, and date :D
15:30:25 <so_solid_moo> http://slexy.org/view/s21SWGWeQU
15:30:29 <LanceHaig> hey hey
15:30:33 <so_solid_moo> ^^ that's what a property set looks like by default
15:30:36 <so_solid_moo> hey Lance
15:31:06 <so_solid_moo> we have message flags, but I don't know if they are the same set of flags
15:32:30 * LanceHaig has read back on the logs
15:33:07 * SM2k finds himself programming a Geode board this morning. :-)
15:33:31 <LanceHaig> so_solid_moo: you mentioned my name earlier
15:33:43 <LanceHaig> is there a task that needs doing?
15:33:49 <so_solid_moo> updating the wiki :)
15:33:50 <fatpelt_laptop> ok.  yeah.  so_solid_moo the only other envleope field is the ip of the server that dropped off the message
15:33:54 <so_solid_moo> *cackle*
15:34:04 * LanceHaig runs
15:34:07 <SM2k> LanceHaig: good morning. :-)
15:34:11 <so_solid_moo> fatpelt_laptop: well, any agent can add any arbitrary property it likes
15:34:12 <SM2k> at least it was 8-)
15:34:17 <LanceHaig> Hey SM2k
15:34:23 <so_solid_moo> so smtpd can put on 'smtp.received_from' or something?
15:34:53 <LanceHaig> Are there specific tasks with the wiki?
15:35:42 <fatpelt_laptop> so_solid_moo: ok.  that's sounds perfect.  i'm not sure that currently there is an agent that uses it, but we could use it to block by ip or something
15:36:35 <fatpelt_laptop> for the queue:  each agent creates an incoming and an outgoing collection and the new queue agent simply moves between one agent's outgoing an anothers incoming right?
15:36:44 <so_solid_moo> basically, yeah
15:37:14 <so_solid_moo> the other thing we're missing is a migrate document command
15:37:21 <so_solid_moo> to move documents from one store to another for delivery
15:37:43 <fatpelt_laptop> oh.  so you are thinking each agent has a store of it's own?
15:38:39 <so_solid_moo> no no, but once the mail has been processed it has to be moved to the user's store
15:38:48 <fatpelt_laptop> *cough*  yeah i knew theat
15:38:57 <so_solid_moo> :)
15:39:11 <fatpelt_laptop> #action add a store migrate command
15:39:33 <so_solid_moo> so are we generally happy with what needs to happen to queue then?
15:39:44 <fatpelt_laptop> i think so yeah
15:39:52 <LanceHaig> question?
15:39:56 <so_solid_moo> sure
15:40:08 <fatpelt_laptop> we need a #raisehand
15:40:13 <fatpelt_laptop> :p
15:40:17 <LanceHaig> will the new queue enable support for external spam tools etc MailScanner
15:40:33 <LanceHaig> that needs an incoming queue and an outgoing queue
15:40:35 <so_solid_moo> nope
15:40:40 <LanceHaig> right
15:40:41 <so_solid_moo> it's a totally different issue
15:40:52 <LanceHaig> ok just checking
15:41:03 <so_solid_moo> however, it probably makes writing such an agent slightly easier I guess
15:42:24 <LanceHaig> So we could write a specific agent to do that
15:42:33 <so_solid_moo> yeah
15:42:40 <LanceHaig> so it wold handel the in and out que andpass any mail on
15:42:41 <LanceHaig> ok
15:42:49 <so_solid_moo> alright
15:42:53 <so_solid_moo> #topic Bongo Manager work
15:43:22 <so_solid_moo> What I want to do is essentially rewrite this, because the current one doesn't work very well
15:43:36 <so_solid_moo> the idea is that it would actually talk to agents directly as well
15:43:49 <so_solid_moo> so it would start the store, read the store config, start the required agents etc.
15:44:03 <so_solid_moo> tell them when to reload their configuration, tell them when to shut down, that kind of thing
15:44:35 <fatpelt_laptop> and collect stats
15:44:43 <so_solid_moo> sure
15:44:51 <fatpelt_laptop> or...    agents could just write that to the store as a document
15:44:56 <so_solid_moo> either way really
15:44:58 <fatpelt_laptop> how intensive is it to update a store doc?
15:45:07 <so_solid_moo> depends what you're doing to it :)
15:45:24 <fatpelt_laptop> if we do that we could have a separate agent to do the snmp.
15:45:40 <fatpelt_laptop> oh... just a document property would be better
15:46:43 <so_solid_moo> potentially we could have a standalone logging agent which handles the stats itself
15:46:50 <so_solid_moo> maybe this is something we should look at for 0.8?
15:47:12 <fatpelt_laptop> any way.  we could either do stat publishing either in -manager or elsewhere.  ok that sounds prefect actually
15:47:30 <fatpelt_laptop> #agreed  stats are a feature for .8
15:47:54 <fatpelt_laptop> #agreed smtpd is a rewrite for .8+
15:48:10 <fatpelt_laptop> (i don't think i did that previously, sorry for the backtrack)
15:48:28 <so_solid_moo> :)
15:49:09 <fatpelt_laptop> so_solid_moo: one other question for queue.  would we ever need/want a separate store jsut to act as a queue?
15:49:25 <so_solid_moo> dunno, tbh
15:49:31 <so_solid_moo> I think that would be after 1.0
15:49:42 <fatpelt_laptop> kk
15:49:45 <so_solid_moo> because we'd need a proper store->store migrate for that
15:51:24 <so_solid_moo> any other bits for manager?
15:51:58 <fatpelt_laptop> don't think so
15:53:29 <so_solid_moo> #topic Store agent work
15:53:40 <so_solid_moo> So, we've already got migrate and any other bits needed to match up to queue
15:53:51 <so_solid_moo> Indexing I think I want to leave until 0.8 sadly
15:53:55 <fatpelt_laptop> body search
15:54:02 <so_solid_moo> right, mail grep
15:54:42 <fatpelt_laptop> i assume that for an agent to drop a message (eg:  virus infected) an agent just doesn't move from incoing to outgoing?
15:55:17 <so_solid_moo> well
15:55:25 <so_solid_moo> I think my take is that agents shouldn't drop any mail
15:55:30 <so_solid_moo> it should be up to the queue agent
15:55:59 <fatpelt_laptop> ok.  so we need a way for an agent to flag a message as dropped in the store.  a new flag perhaps?
15:56:41 <so_solid_moo> well, in the case of viruses, I think you'd just set a properly like 'avirus.status' to 'clear', 'infected', etc.
15:56:57 <so_solid_moo> and then something else decides that things marked 'infected' go into quarantine or something
15:57:15 <fatpelt_laptop> hmm.  ok.
15:58:03 <fatpelt_laptop> i think that'll need to be a part of the avirus agent.  else it would get nasty as you'd hve to modify queue for every new agent people write that might want to drop email for some reason
15:58:34 <so_solid_moo> Right, but why wouldn't this be part of the system rules or something?
15:59:31 <fatpelt_laptop> the system would have to be modified to say: "if avirus.status == infected then drop"  right?
16:00:06 <so_solid_moo> I think that ought to be a configuration you can set rather than a piece of code
16:00:26 <fatpelt_laptop> *thinking*
16:00:27 <so_solid_moo> for some it might be drop, others may want to deliver as-is, others may want a quarantine
16:01:06 <LanceHaig> it enables per user config
16:01:14 <LanceHaig> which would be a nice thing to have
16:01:23 <LanceHaig> any new agent could then have per user config
16:01:23 <so_solid_moo> well, either per-user or per-system
16:01:28 <LanceHaig> yup
16:01:46 <so_solid_moo> I don't think we have to encode mail moving / management rules into agents tho
16:02:08 <fatpelt_laptop> but how would you represent that to the queue/store such that i wouldn't have to modify the system if i write a new agent that sets (say) if (patsamazingagent.status = patdoesnotrock) then drop" ?
16:02:38 <so_solid_moo> fatpelt_laptop: I think that ought to be something you can configure the rules agent to do
16:02:41 <fatpelt_laptop> (as obviously that would be a mail worthy of dropping)
16:02:45 <so_solid_moo> hehe
16:02:57 <fatpelt_laptop> *thinking*
16:03:13 <so_solid_moo> I mean, let's take a slightly better example : antispam
16:03:24 <so_solid_moo> you can do status as 'ham' or 'spam'
16:03:36 <so_solid_moo> but then you can also have spam-score as (e.g.) a number between 0 and 10
16:03:46 <so_solid_moo> some people may want to drop 8+, others will want everything
16:03:52 <so_solid_moo> hardcore people will drop 3+
16:04:27 <fatpelt_laptop> ok. i don't see any problems here
16:05:15 <so_solid_moo> what would be nice would be if agents dropped in the system somewhere, on install, a json doc describing what tweaks they make to mails in terms of properties/whatever
16:05:20 <so_solid_moo> then the rules agent ui could automatically pick that up
16:05:42 <so_solid_moo> so you don't have to know the property is "avirus.status", etc.
16:05:58 <fatpelt_laptop> what about precedence?  what if i need a system setting for rules to quarantine mail?
16:06:41 <so_solid_moo> I think that's up to the designer of the rules agent :D
16:06:55 <fatpelt_laptop> poor guy
16:06:56 <so_solid_moo> I think it's probably useful to have a system doc which gets processed first before the user's own doc
16:07:09 <so_solid_moo> or maybe per-system, then per-domain, then per-user... ?
16:07:27 <LanceHaig> yes you would need those three level
16:07:29 <LanceHaig> levels even
16:07:32 <fatpelt_laptop> that would be good.  i think LanceHaig would like that
16:07:35 <fatpelt_laptop> ;D
16:07:39 <LanceHaig> I would
16:07:53 * fatpelt_laptop will be right b ack
16:07:55 <LanceHaig> it just means we have a killer antivirus/spam system
16:10:25 <fatpelt_laptop> sorry.  the boy took a spill on the sidewalk
16:10:29 <fatpelt_laptop> back now
16:10:53 <so_solid_moo> oops
16:11:04 <fatpelt_laptop> he's ok. :)
16:11:41 <fatpelt_laptop> there is currently a way for an agent to duplicate a message in a given queue
16:12:10 <so_solid_moo> yup
16:12:23 <LanceHaig> what wold be the use case for a duplicate document?
16:12:36 <fatpelt_laptop> is that just a document copy?
16:12:46 <LanceHaig> I would have thought that not good for storage or performance
16:12:55 <so_solid_moo> it is just document copy
16:13:02 <so_solid_moo> however, I don't think it copies the document body
16:13:13 <so_solid_moo> as in, you get single instance effectively
16:13:33 <fatpelt_laptop> nah, it'll copy the body because i may have modified the message headers
16:13:38 <LanceHaig> ahh
16:13:46 <fatpelt_laptop> LanceHaig: one possibility (in the old system) would be to archive all mail
16:13:48 <so_solid_moo> ah, right
16:14:23 <LanceHaig> ahh yes
16:14:28 <LanceHaig> I rememebr now
16:14:30 <LanceHaig> ok
16:15:51 <fatpelt_laptop> or, in the case of antispam for example:  i modify the headers, but perhaps there is some agent in an earlier queue that i need to see the new modified email
16:16:14 <fatpelt_laptop> then i drop the original
16:17:42 <fatpelt_laptop> so_solid_moo: does the store allow for more than one recipient in the properties?
16:17:47 <so_solid_moo> yeah
16:17:49 <so_solid_moo> don't ask me how :D
16:18:03 <fatpelt_laptop> is the to stored as a document property?
16:18:07 <so_solid_moo> yeah
16:18:22 <so_solid_moo> I can't recall if it gets split into constituent parts tho
16:18:23 <fatpelt_laptop> could you then just add multiple document.to properties?
16:18:37 * so_solid_moo looks
16:18:38 <fatpelt_laptop> oh.  sorry.  bongo.to
16:20:26 <so_solid_moo> ah, no, you just get the To: line
16:20:28 <so_solid_moo> commas and all
16:22:31 <fatpelt_laptop> hmm.  we might want to change that ?
16:23:22 <fatpelt_laptop> for example
16:23:50 <fatpelt_laptop> a message comes if for fatpelt,pfelt,abuse.  the rules agent determines that fatpelt and pfelt don't want it.  how does that work?
16:24:10 <so_solid_moo> oh, but that's three separate mails on the system though, no?
16:24:30 <so_solid_moo> ah, hang on
16:24:36 <fatpelt_laptop> in the current system it isn't
16:24:37 <so_solid_moo> bongo.to != envelope to
16:24:46 <so_solid_moo> currently we don't have the envelope stuff on file
16:25:00 <fatpelt_laptop> ah.  so we just add envelope.* fields
16:25:02 * so_solid_moo has just had a branewave
16:25:03 <so_solid_moo> yeah
16:25:10 <so_solid_moo> or smtp.*
16:25:11 <so_solid_moo> or whatever
16:25:13 <fatpelt_laptop> then we can support whatever we need
16:25:16 <so_solid_moo> right
16:25:42 <fatpelt_laptop> and that isn't a modification to store really as we already support that stuff
16:27:08 <so_solid_moo> I believe so
16:29:52 <so_solid_moo> anything else we need to do / talk about with the store?
16:30:24 <fatpelt_laptop> i think we might be done with store
16:30:33 <fatpelt_laptop> looking over the queue protocol spec
16:32:14 * fatpelt_laptop is going to have to go shortly, but will be back after the dentist :(
16:32:24 <so_solid_moo> hehe, np
16:32:28 <so_solid_moo> how long are you away for?
16:32:37 <fatpelt_laptop> not sure, but probably not any longer than an hour
16:32:45 <fatpelt_laptop> depends on what he wants to poke me with
16:32:48 <so_solid_moo> heh
16:33:03 <so_solid_moo> I suspect I might be busy by then for a couple of hours :S
16:33:18 <so_solid_moo> We have web ui basically left to talk about, and any other bits for 0.7
16:33:52 <fatpelt_laptop> don't stop the meeting on my account.  i'll read the backlog/minutes
16:34:06 <so_solid_moo> well, I don't know if there's anyone else but me and Lance tbh
16:34:15 <so_solid_moo> better to have another go when more people are about I think
16:37:21 <so_solid_moo> ok, let's call it quits for now
16:37:23 <so_solid_moo> #endmeeting