Re: [sup-talk] sup-server

From: Andrei Thorp <garoth@gmail.com>
To: sup-talk@rubyforge.org, rlane@club.cc.cmu.edu
Subject: Re: [sup-talk] sup-server
Date: Tue, 8 Dec 2009 17:12:05 -0500	[thread overview]
Message-ID: <80055d7c0912081412h483bc6dt8493b08dfab1d23b@mail.gmail.com> (raw)
In-Reply-To: <1260291857-sup-4773@zyrg.net>

On Tue, Dec 8, 2009 at 1:56 PM, Rich Lane <rlane@club.cc.cmu.edu> wrote:
> 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
>

While I'm as usual very impressed that Rich has done so much work, and
very happy with the ideas proposed in the STS posts, I can't help but
wonder,

"Why does this sound like implementing a Sup ui to Wave, but not using
Wave?" (Actually mentioned in Rethinking Sup pt. 2)

This really seems like it's in direct competition with the Wave
system... but Wave has a lot more support. And yes, Wave doesn't have
e-mail federation at the moment, but I think they plan to do that in
the future. So yes, I like the idea of a Sup server, I like being able
to access my (sup) mail from multiple computers, I like the idea of
having multiple UIs to the Sup Service... but I think that in the long
run, I'd feel just as good about a couple good open source UIs to
Google's Wave instead.

Honestly, I hope I'm wrong since there seems to be a lot of work done
here. Also, I have a Wave account and some invites, so if you want to
do some research and get a preview account, I can give some out.

Cheers,

-Andrei Thorp
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk