From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.90.27.4 with SMTP id a4cs13988aga; Tue, 8 Dec 2009 10:56:25 -0800 (PST) Received: by 10.224.51.222 with SMTP id e30mr4796946qag.82.1260298584148; Tue, 08 Dec 2009 10:56:24 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id 6si9653279qyk.71.2009.12.08.10.56.24; Tue, 08 Dec 2009 10:56:24 -0800 (PST) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id D5FDD1D78875 for ; Tue, 8 Dec 2009 13:56:23 -0500 (EST) Received: from pion.club.cc.cmu.edu (PION.CLUB.CC.cmu.edu [128.237.157.88]) by rubyforge.org (Postfix) with ESMTP id DC5EA1D78869 for ; Tue, 8 Dec 2009 13:56:10 -0500 (EST) Received: from rlane by pion.club.cc.cmu.edu with local (Exim 4.69) (envelope-from ) id 1NI5EI-0000sX-Fx for sup-talk@rubyforge.org; Tue, 08 Dec 2009 13:56:10 -0500 From: Rich Lane To: sup-talk Date: Tue, 08 Dec 2009 13:56:10 -0500 Message-Id: <1260291857-sup-4773@zyrg.net> User-Agent: Sup/git Subject: [sup-talk] sup-server X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org 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