Re: [sup-talk] sup web interface

From: Rich Lane <rlane@club.cc.cmu.edu>
To: Jason Petsod <jason@petsod.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sup web interface
Date: Fri, 04 Jun 2010 23:55:03 -0400	[thread overview]
Message-ID: <1275706760-sup-1122@zyrg.net> (raw)
In-Reply-To: <1275666025-sup-4912@acheron.quadco.net>

Excerpts from Jason Petsod's message of 2010-06-04 11:59:15 -0400:
> For threading, I had to add a new command 'thread' to sup-server, so you'll
> need to apply a patch [2] before it works. 

I've applied this to master. However, I think the final protocol support
for threading is going to be more complicated. Right now in the best
case this is going to result in a request for every thread displayed,
and in the worst case where thread requests are pipelined we could have
a lot of redundant message responses. The best I've come up with is
adding a "thread" option to query that mimics ThreadSet#load_n_threads.

> Also, it's not evident to me that the sup-server polls for new messages or
> has the ability to add new messages to the index, so checking for new
> messages or sending emails doesn't work yet. That functionality shouldn't
> hard to add though.

Yeah, I need to add a timer to periodically poll the sources. But it
should be possible to use the add request already to add sent messages
to the index.

I took a quick look at sup-web. I think it would be a good idea to spawn
an EM reactor thread when the webapp starts (if the server isnt already
using one) instead of starting one per sup protocol request. Similarly,
you'll probably want to keep a connection pool instead of opening a new
connection per sup protocol request.
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk