I've pushed a branch sup-server to my github*. There's a lot to be done before this reaches feature parity with current Sup - for instance, the ncurses client doesn't work yet.
*git://github.com/rlane/sup Current status: - Server passes its (incomplete) test suite - sup-cmd executable useful for simple interactions (each protocol request exposed) - ncurses client completely nonfunctional - client/server/common source code split - server implemented with Revactor - Ruby 1.9 only - server stores messages (currently gzip'd mbox-ish) Protocol: - Designed to avoid round-trip latencies - BERT over tcp/unix - thrift/etc could be supported in the future - Requests (full docs in lib/sup/server/requests.rb): - Query - Count - Label - Add - Stream - Cancel - Requests take query arguments instead of messages-ids (thanks to Carl/notmuch for this idea) - These requests should be sufficient to implement a working client. We can add more in the future for optimizations (threading) or new features (contacts). TODO: - Expand test suite - Modify sup-sync to send Add requests to the server - Get the ncurses UI working - Remove dead code - Protocol versioning/negotiation/authentication/extensions - Performance optimizations - Add web/android/iphone/vim/irb/etc UIs - Actorize the index/storage interfaces - Shard index/storage - Distribute indexing/parsing/compression/etc across worker processes - Replication? The test suite is an important part of this effort. With the amount of code churn that's going on it just takes too much work to manually verify that every (affected) feature works before committing. If it's not covered by a test, I don't care if it's broken. For now, I'll plan on adding any new UIs to the main repo. When the protocol stabilizes we can think about splitting them out. I would be very interested if someone could spin up a web UI quickly. I'd like to start using this branch for my own mail and it will take a significant amount of time before I can beat the ncurses UI into shape. For some background on sup-server please read William's various blog posts on the subject. In its current form this project makes some compromises for the sake of efficiency and simplicity. I would be interested in making the protocol more generic while preserving those attributes, so if you have thoughts on this send them to the list. Some questions from the IRC channel: - Do clients need threading logic? Yes. There is no thread abstraction in the protocol, so clients will need to understand email threading. A planned optimization is to expose the index thread-id field to essentially collapse the thread for client-threading purposes. - Will a client connecting to sup-server feel snappier than sup over ssh? Yes (given a well-written client). The protocol is designed to minimize the effects of network latency, but it will take a good amount of work in the client to fully take advantage of this. - Do clients need to know how to parse email? Yes. Right now clients who want to display a message need to query for the raw message text. If we can come up with a simple, comprehensive model of an email message that clients would rather digest than the raw text I'd be willing to add it as an optional extension to the protocol. _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
