librelist archives

[newman] Re: new proposal: Newman application for scheduling meetings

From:

Eric G

Date:

2012-02-22 @ 17:48

OK, I had a stab at this and my head is spinning a bit at the various
issues.  Here's my current thoughts.  See what you think.

1. It would be nice if people's weekly availability weren't tied to a
particular event/mailing list.  Then people could just send in their
available times once, and different events could use the same data to
determine "best times" for as-yet-unscheduled events.

2. In terms of integration with mail_whale, I'm thinking the scheduler app
is mounted in front of mail_whale. The scheduler, like mail_whale, will
match routes on the "to" address. Certain "to" addresses the scheduler will
handle doing the response, others will pass down to mail_whale.

So for the server logic, in cases like this I think it would really help to
have a way for an application to say *"stop processing callbacks that
affect the response"*.  (At first I was thinking this would be equivalent
to `halt` in Sinatra, break out of the applications loop in #tick and just
deliver the response, but then that would skip over things like the
ResponseLogger which don't affect the response).  I have a couple ideas
about this, could put them up in the issue tracker to discuss if you want.

Here's the new proposed interactions:

  Request
 To
 Subject
 Body
 Response
  Send in my availability for the week of Feb 2
 c+availability.2012-02-20@domain
 +09:00  (timezone offset)

If blank, then assume UTC (or assume timezone of sent date field?)
 Mon Wed Fri
3pm - 7pm

Tue Thu
11:30am - 6pm
 scheduler: none (store/update availability record keyed by email address
and week)
mail_whale: Forward to subscribers of an "availability" mailing list [1]
  What are the current best times to meet for all subscribers to
some-event, 90 minute event?
 c+some-event.schedule.90@domain [2]
 ?
 (ignored)
 scheduler: Reply with best scheduled times to subscribers of "some-event"
mailing list, using the stored availability records [3]
mail_whale: none (processing halted by scheduler)
  What are the current available timeslots for some-user for some-event?
 c+some-event.schedule.90@domain
 ?some-user@domain
 (ignored)
 scheduler: Reply with all available times for some-user@domain to sender.
The user doesn't necessarily have to be a subscriber to the "some-event"
list.
mail_whale: none (processing halted by scheduler)


Notes:
[1]: For this to work right, mail_whale should `match :list_id, "[^\.]+"`
-- i.e. only up to the first period in the "to" tag.

[2]: Ideally, the duration of the event should be encoded somehow
(optionally) when the mailing list is created, so it doesn't have to be
sent each time with these "scheduler query" requests. But that would mean a
bit of a change to the way mailinglists are persisted, since right now only
the subscribers are saved, nothing about the event which they are connected
to.

[3]: Likewise, the scheduler would need to know the week or date of the
event when looking up people's availability, so that would need to be saved
with the mailinglist as well.

Draft implementation (well, minus the models) here:
https://gist.github.com/27d8bced6b88ecd53b06

Took a brief look, in general, please charge ahead on this and we'll 
discuss once you have a working solution you're happy with. You may want 
to punt some of these questions to the mendicant-alumni list since 
they're the ones that will be using this tool.

Some specific notes.

On 2/22/12 12:48 PM, Eric G wrote:
> OK, I had a stab at this and my head is spinning a bit at the various
> issues.  Here's my current thoughts.  See what you think.
>
> 1. It would be nice if people's weekly availability weren't tied to a
> particular event/mailing list.  Then people could just send in their
> available times once, and different events could use the same data to
> determine "best times" for as-yet-unscheduled events.

Sounds like a nice feature but let's defer it for now. There may be edge 
cases to that, and we don't have enough meetings each week where there 
is a lot of

> So for the server logic, in cases like this I think it would really help
> to have a way for an application to say /"stop processing callbacks that
> affect the response"/.

As I think through this, I think perhaps that the right way to go is 
introducing some sort of top-level routing. For example, it might be 
nice to build a composite application which essentially uses somewhat 
generic matchers to forward the requests to one of the apps it wraps.

Do any ideas come to mind hearing that? If not I can try to sketch up an 
example. I think this sort of approach is generally safer than a 
load-order dependent halting/response freezing mechanism.

-greg

OK, probably should have something by Monday.

As I think through this, I think perhaps that the right way to go is
> introducing some sort of top-level routing. For example, it might be
> nice to build a composite application which essentially uses somewhat
> generic matchers to forward the requests to one of the apps it wraps.
> Do any ideas come to mind hearing that? If not I can try to sketch up an
> example. I think this sort of approach is generally safer than a
> load-order dependent halting/response freezing mechanism.


Exactly what I was starting to think about. Something like Rack::URLMap.

The other thing that came to mind was to have nested matchers so you could
define a callback that runs when eg. both a to-tag and subject matcher are
true. Sort of like soveran/cuba <https://github.com/soveran/cuba> ' s
routing. But I think that leads to unnecessarily complicated code for not
much real usefulness.

In the meantime I don't know if you saw my ideas about some conventions for
avoiding 'routing collisions'.
https://gist.github.com/27d8bced6b88ecd53b06#file_2_address_conventions.md


On Fri, Feb 24, 2012 at 12:25 PM, Gregory Brown <
gregory_brown@letterboxes.org> wrote:

> Took a brief look, in general, please charge ahead on this and we'll
> discuss once you have a working solution you're happy with. You may want
> to punt some of these questions to the mendicant-alumni list since
> they're the ones that will be using this tool.
>
> Some specific notes.
>
> On 2/22/12 12:48 PM, Eric G wrote:
> > OK, I had a stab at this and my head is spinning a bit at the various
> > issues.  Here's my current thoughts.  See what you think.
> >
> > 1. It would be nice if people's weekly availability weren't tied to a
> > particular event/mailing list.  Then people could just send in their
> > available times once, and different events could use the same data to
> > determine "best times" for as-yet-unscheduled events.
>
> Sounds like a nice feature but let's defer it for now. There may be edge
> cases to that, and we don't have enough meetings each week where there
> is a lot of
>
> > So for the server logic, in cases like this I think it would really help
> > to have a way for an application to say /"stop processing callbacks that
> > affect the response"/.
>
> As I think through this, I think perhaps that the right way to go is
> introducing some sort of top-level routing. For example, it might be
> nice to build a composite application which essentially uses somewhat
> generic matchers to forward the requests to one of the apps it wraps.
>
> Do any ideas come to mind hearing that? If not I can try to sketch up an
> example. I think this sort of approach is generally safer than a
> load-order dependent halting/response freezing mechanism.
>
> -greg
>

On 2/24/12 7:27 PM, Eric G wrote:
> OK, probably should have something by Monday.

> In the meantime I don't know if you saw my ideas about some conventions
> for avoiding 'routing collisions'.
> https://gist.github.com/27d8bced6b88ecd53b06#file_2_address_conventions.md

Have not read it yet, but will do so over the weekend if I find time. 
It's another thing to bug me about if I don't get to it soon.

-greg