[sup-devel] sup-server revisited

* [sup-devel] sup-server revisited
@ 2011-02-21 21:02 William Morgan
  2011-02-22 13:46 ` Mark Alexander
                   ` (3 more replies)
  0 siblings, 4 replies; 27+ messages in thread
From: William Morgan @ 2011-02-21 21:02 UTC (permalink / raw)
  To: sup-talk, sup-devel

Hello Sup fans,

As I alluded to in an earlier email to sup-devel, I have been working recently
on the ancient goal of splitting Sup functionality out into separate client and
server programs. This will have many advantages; in particular it will remove
email lock-in by making it possible to have non-Sup clients interact with Sup.

I've tried various approaches to this goal at various times, without much
success. But with the release of Whistlepig, I have been making a lot of
progress in a short amount of time.

I wanted to lay out my general plan in this email, so that everyone can follow
along and try things out if they feel inclined.

I'm focusing on the server component first. My specific goals are:

- Encapsulate all storage and indexing logic.
- Formalize the notion of labels and state, and the relationship between them,
  messages, and threads. Currently these relationships are fuzzy in Sup, and
  things suffer for it.
- Precompute threads, so that search requires only moderate effort, instead of
  the large effort it does now. This will make search much, much faster, at the
  expense of a little more effort at index time.
- Allow concurrent access from multiple clients.
- Provide something that is transparent and easy to modify without having to go
  through an ncurses client.

You can find the work in progress here: https://github.com/wmorgan/heliotrope
Currently it is not actually a server, but accomplishes many of the goals
above. Run bin/email-indexer and then bin/email-searcher to play around with
a simple preview of things to come. Stay tuned for more on this.

Once the server is in a reasonable state, my goals for the curses client reboot
are:

- Move to an event-based model rather than the polling + many threads +
  observable model we have now. Dump all events into one big queue,
  and block on it.
- Have one, and only one, non-main thread, which it to communicate with the
  server. No more mutex insanity.
- Work from the ground up with Ruby 1.9, which means finding the many sources
  of encoding errors and punishing them.
- Require the console and ncurses gems so that i18n works out of the box.
- Borrow as much code as possible from the current Sup, because I sure as shit
  don't want to have to rewrite it all.

I haven't started on this at all.

So stay tuned, and check out heliotrope if you are so inclined.

-- 
William <wmorgan-sup@masanjin.net>
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel

^ permalink raw reply	[flat|nested] 27+ messages in thread