From vb@haramis.fdn.fr Tue Jul 1 05:43:39 2008 From: vb@haramis.fdn.fr (Vincent Bernardoff) Date: Tue, 1 Jul 2008 11:43:39 +0200 Subject: [sup-talk] Sup crashed Message-ID: <20080701094339.GC28663@anigel> vb~haramis (~)% sup [Tue Jul 01 11:48:50 +0200 2008] using character set encoding "UTF-8" [Tue Jul 01 11:48:51 +0200 2008] optional 'chronic' library not found (run 'gem install chronic' to install) [Tue Jul 01 11:48:51 +0200 2008] locking /home/vb/.sup/lock... [Tue Jul 01 11:48:51 +0200 2008] crypto: detected gpg binary in /usr/bin/gpg [Tue Jul 01 11:48:51 +0200 2008] stopped cursing [Tue Jul 01 11:48:51 +0200 2008] oh crap, an exception [Tue Jul 01 11:48:51 +0200 2008] unlocking /home/vb/.sup/lock... ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the contents of sup-exception-log.txt and a brief report of the circumstances to sup-talk at rubyforge dot orgs so that I might address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- ArgumentError from thread: main wrong number of arguments (2 for 1) /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:422:in `respond_to?' /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:422:in `flatten' /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:422:in `load_sources' /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:108:in `load' /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/util.rb:497:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/util.rb:497:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:121 /usr/bin/sup:19:in `load' /usr/bin/sup:19 Installed with gem 1.1.1 on archlinux x86_64. (command: gem install sup) Thank in advance, -- Vincent Bernardoff From wmorgan-sup@masanjin.net Wed Jul 2 09:47:44 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 02 Jul 2008 06:47:44 -0700 Subject: [sup-talk] Sup crashed In-Reply-To: <20080701094339.GC28663@anigel> References: <20080701094339.GC28663@anigel> Message-ID: <1215006339-sup-6551@entry> Reformatted excerpts from Vincent Bernardoff's message of 2008-07-01: > wrong number of arguments (2 for 1) > /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:422:in > `respond_to?' This is due to ruby 1.8.7. It's fixed in git, if you want to try that, or you can apply this patch directly: http://repo.or.cz/w/sup.git?a=blobdiff;f=lib/sup/util.rb;fp=lib/sup/util.rb;h=9909022ffa9b0b1c5796f4fbdff925087dec2519;hp=ceaf0b8dabc8a83ea451005e9b27bc109823caf1;hb=7baf2ae82255b4ca77a1e2a4b46831371f92cfce;hpb=21e34247462f5a0ca69dc2de46eceb21e5f1fb58 -- William From eric.williams@redhat.com Thu Jul 3 03:34:48 2008 From: eric.williams@redhat.com (Eric Williams) Date: Thu, 03 Jul 2008 08:34:48 +0100 Subject: [sup-talk] Mark tagged as read/unread? Message-ID: <1215069949-sup-6698@eric.fab.redhat.com> Hi, Sup people! I'm trying to find something in sup that is really bogeying up my workflow at the moment. Is there a way to mark a bunch of tagged messages as Read or Unread? I can only find a toggle at the moment, which is pretty useless if you've tagged a bunch of threads of mixed read/unread status. I would like to tag a bunch of messages, mark them all as read (regardless of their current status), them ship 'em off to the archive. Is there a keystroke not listed in the help page? Thanks, eric -- Eric Williams GSS-EMEA 08:34:01 up 1 day, 17:40, 1 user, load average: 0.18, 0.27, 0.33 From fedzor@gmail.com Thu Jul 3 11:26:06 2008 From: fedzor@gmail.com (fedzor) Date: Thu, 3 Jul 2008 11:26:06 -0400 Subject: [sup-talk] Sending Emails Message-ID: its not as dumb of a question as you think! I prowled around in the source, and i even used grep tons of times to find where the messages are *actually* sent in the code, but I can't find it. Mr. Morgan, I can only assume that you know exactly where this is. Could you point me to it? -------------------------------------------------------| ~ Ari if god gives you lemons YOU FIND A NEW GOD From its.jeff.balogh@gmail.com Thu Jul 3 11:38:35 2008 From: its.jeff.balogh@gmail.com (Jeff Balogh) Date: Thu, 03 Jul 2008 11:38:35 -0400 Subject: [sup-talk] Sending Emails In-Reply-To: References: Message-ID: <1215099271-sup-5787@archie> fedzor wrote: > its not as dumb of a question as you think! > > I prowled around in the source, and i even used grep tons of times to > find where the messages are *actually* sent in the code, but I can't > find it. > > Mr. Morgan, I can only assume that you know exactly where this is. > Could you point me to it? I'm not Mr. Morgan, but... $ ack sendmail lib/sup.rb 211: :sendmail => "/usr/sbin/sendmail -oem -ti", lib/sup/modes/edit-message-mode.rb --> 285: IO.popen(acct.sendmail, "w") { |p| p.puts m } 286: raise SendmailCommandFailed, "Couldn't execute #{acct.sendmail}" unless $? == 0 lib/sup/account.rb 4: attr_accessor :sendmail, :signature 10: @sendmail = h[:sendmail] 40: [:name, :sendmail, :signature].each { |k| hash[k] ||= @default_account.send(k) } The call is in send_message in lib/sup/modes/edit-message-mode.rb, line 285 in git-next. Cheers, jeff From wmorgan-sup@masanjin.net Thu Jul 3 11:51:35 2008 From: wmorgan-sup@masanjin.net (wmorgan-sup at masanjin.net) Date: Thu, 03 Jul 2008 08:51:35 -0700 Subject: [sup-talk] Mark tagged as read/unread? In-Reply-To: <1215069949-sup-6698@eric.fab.redhat.com> References: <1215069949-sup-6698@eric.fab.redhat.com> Message-ID: <1215100280-sup-4628@entry> Reformatted excerpts from Eric Williams's message of 2008-07-03: > I'm trying to find something in sup that is really bogeying up my > workflow at the moment. Is there a way to mark a bunch of tagged > messages as Read or Unread? I can only find a toggle at the moment, > which is pretty useless if you've tagged a bunch of threads of mixed > read/unread status. There's no way to do that but it would be pretty trivial to add. -- William From wmorgan-sup@masanjin.net Thu Jul 3 11:52:35 2008 From: wmorgan-sup@masanjin.net (wmorgan-sup at masanjin.net) Date: Thu, 03 Jul 2008 08:52:35 -0700 Subject: [sup-talk] Sending Emails In-Reply-To: <1215099271-sup-5787@archie> References: <1215099271-sup-5787@archie> Message-ID: <1215100319-sup-947@entry> Reformatted excerpts from its.jeff.balogh's message of 2008-07-03: > lib/sup/modes/edit-message-mode.rb > --> 285: IO.popen(acct.sendmail, "w") { |p| p.puts m } > 286: raise SendmailCommandFailed, "Couldn't execute #{acct.sendmail}" > unless $? == 0 Yep, this is the actual execution point. It's a call out to whatever sendmail program you've defined in your configuration. -- William From grant@antiflux.org Thu Jul 3 08:30:46 2008 From: grant@antiflux.org (Grant Hollingworth) Date: Thu, 03 Jul 2008 08:30:46 -0400 Subject: [sup-talk] Mark tagged as read/unread? In-Reply-To: <1215069949-sup-6698@eric.fab.redhat.com> References: <1215069949-sup-6698@eric.fab.redhat.com> Message-ID: <1215088116-sup-502@spooky.local> * Eric Williams [2008-07-03 03:34 -0400]: > I'm trying to find something in sup that is really bogeying up my workflow > at the moment. Is there a way to mark a bunch of tagged messages as Read or > Unread? I can only find a toggle at the moment, which is pretty useless if > you've tagged a bunch of threads of mixed read/unread status. I would like > to tag a bunch of messages, mark them all as read (regardless of their > current status), them ship 'em off to the archive. Is there a keystroke not > listed in the help page? There's 'A' (for read_and_archive) but it only works in the inbox. What mode are these messages in? From ecoffey@gmail.com Thu Jul 3 19:08:27 2008 From: ecoffey@gmail.com (Eoin Coffey) Date: Thu, 3 Jul 2008 17:08:27 -0600 Subject: [sup-talk] Sup initalize setup crash Message-ID: <2d88cc360807031608i44d90bf1o402a0666a737e8d8@mail.gmail.com> Just finished sup-config and configured for secure imap (its a gmail account). -Eoin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sup-exception-log.txt URL: From wmorgan-sup@masanjin.net Thu Jul 3 20:55:37 2008 From: wmorgan-sup@masanjin.net (wmorgan-sup) Date: Thu, 03 Jul 2008 17:55:37 -0700 Subject: [sup-talk] Sup initalize setup crash In-Reply-To: <2d88cc360807031608i44d90bf1o402a0666a737e8d8@mail.gmail.com> References: <2d88cc360807031608i44d90bf1o402a0666a737e8d8@mail.gmail.com> Message-ID: <1215132892-sup-2132@entry> Reformatted excerpts from Eoin Coffey's message of 2008-07-03: > wrong number of arguments (2 for 1) > /usr/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/index.rb:422:in `respond_to?' This is due to ruby 1.8.7. It's fixed in git, if you want to try that, or you can apply this patch directly: http://repo.or.cz/w/sup.git?a=blobdiff;f=lib/sup/util.rb;fp=lib/sup/util.rb;h=9909022ffa9b0b1c5796f4fbdff925087dec2519;hp=ceaf0b8dabc8a83ea451005e9b27bc109823caf1;hb=7baf2ae82255b4ca77a1e2a4b46831371f92cfce;hpb=21e34247462f5a0ca69dc2de46ece Since you're the fourth person to report this in the past few weeks, I suppose this means it's time to release a new version of Sup... -- William From georg@xtna.de Tue Jul 15 04:59:55 2008 From: georg@xtna.de (Georg Lehmann) Date: Tue, 15 Jul 2008 10:59:55 +0200 Subject: [sup-talk] oh crap, an exception Message-ID: <1216111841-sup-5352@horst> Hi, First: thanks a lot for sup. Great email client/service ;) After sup-add mbox+ssh://koef.xxxx.net/var/mail/grl: [Tue Jul 15 10:12:44 +0200 2008] stopped cursing [Tue Jul 15 10:12:44 +0200 2008] oh crap, an exception [Tue Jul 15 10:12:44 +0200 2008] unlocking /home/georg/.sup/lock... ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the contents of sup-exception-log.txt and a brief report of the circumstances to sup-talk at rubyforge dot orgs so that I might address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- NoMethodError from thread: call #connect on mbox+ssh://koef.xxxx.net/var/mail/grl undefined method `shell' for # /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:175:in `unsafe_connect' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:170:in `synchronize' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:170:in `unsafe_connect' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:192:in `do_remote' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:117:in `connect' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-loader.rb:37:in `connect' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-loader.rb:61:in `safely' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-loader.rb:37:in `connect' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/util.rb:548:in `send' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/util.rb:548:in `__pass' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/util.rb:537:in `method_missing' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:203 /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:60:in `reporting_thread' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:58:in `initialize' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:58:in `new' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:58:in `reporting_thread' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:201 /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:199:in `each' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:199 /opt/local/bin/sup:19:in `load' /opt/local/bin/sup:19 --- SystemExit from thread: main undefined method `shell' for # /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:64:in `select' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/buffer.rb:31:in `nonblocking_getch' /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:227 /opt/local/bin/sup:19:in `load' /opt/local/bin/sup:19 (Sorry for obfuscation) I use ssh-agent, but it also doesnt work with user/pass in sources.yaml Installed ruby/gem manually on debian etch and sup with gem install sup. Kernel: 2.6.18-4-amd64 best regards, Georg Lehmann From wmorgan-sup@masanjin.net Wed Jul 16 20:00:26 2008 From: wmorgan-sup@masanjin.net (wmorgan-sup) Date: Wed, 16 Jul 2008 17:00:26 -0700 Subject: [sup-talk] oh crap, an exception In-Reply-To: <1216111841-sup-5352@horst> References: <1216111841-sup-5352@horst> Message-ID: <1216248900-sup-5089@entry> Reformatted excerpts from Georg Lehmann's message of 2008-07-15: > After sup-add mbox+ssh://koef.xxxx.net/var/mail/grl: > --- NoMethodError from thread: call #connect on > mbox+ssh://koef.xxxx.net/var/mail/grl > undefined method `shell' for # > /opt/local/lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/mbox/ssh-file.rb:175:in > `unsafe_connect' Hm. I actually haven't tried mbox+ssh since the very early days of Sup, so that code has definitely experienced bitrot. I'll look into it. -- William From wmorgan-sup@masanjin.net Sun Jul 20 17:33:24 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 20 Jul 2008 14:33:24 -0700 Subject: [sup-talk] rethinking sup part ii Message-ID: <1216589569-sup-1520@entry> In which the new version of Sup is described! http://all-thing.net/2008/07/rethinking-sup-part-ii.html -- William From guillaume.quintard@gmail.com Sun Jul 20 19:28:44 2008 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sun, 20 Jul 2008 16:28:44 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216589569-sup-1520@entry> References: <1216589569-sup-1520@entry> Message-ID: <1216596306-sup-2450@altis> Excerpts from William Morgan's message of Sun Jul 20 14:33:24 -0700 2008: > In which the new version of Sup is described! > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html looks cool to me (mostly the server/client idea). I just have one question: I am currently using gmail+mpop, and giving the mbox file to sup. The new sup won't change a lot for me, will it? (maybe a stupid question, but I'd like to be sure I understood the implications). -- Guillaume From wmorgan-sup@masanjin.net Sun Jul 20 20:04:35 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 20 Jul 2008 17:04:35 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216596306-sup-2450@altis> References: <1216589569-sup-1520@entry> <1216596306-sup-2450@altis> Message-ID: <1216598629-sup-896@entry> Reformatted excerpts from guillaume.quintard's message of 2008-07-20: > I just have one question: I am currently using gmail+mpop, and giving > the mbox file to sup. The new sup won't change a lot for me, will it? > (maybe a stupid question, but I'd like to be sure I understood the > implications). It should be basically the same, except that you can throw away the mbox file when you're done (because STS will handle the storage for you). -- William From guillaume.quintard@gmail.com Mon Jul 21 01:43:40 2008 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sun, 20 Jul 2008 22:43:40 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216598629-sup-896@entry> References: <1216589569-sup-1520@entry> <1216596306-sup-2450@altis> <1216598629-sup-896@entry> Message-ID: <1216618816-sup-459@altis> Excerpts from William Morgan's message of Sun Jul 20 17:04:35 -0700 2008: > It should be basically the same, except that you can throw away the mbox > file when you're done (because STS will handle the storage for you). Ok, that was what I understood. I'd keep the mbox anyway, having a standard backup format is always nice. -- Guillaume From peter.krenn@gmail.com Mon Jul 21 08:14:05 2008 From: peter.krenn@gmail.com (Peter Krenn) Date: Mon, 21 Jul 2008 14:14:05 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216589569-sup-1520@entry> References: <1216589569-sup-1520@entry> Message-ID: <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> Sounds great. What kind of interface will this service provide? Or will it be more like a library which one could use to access the sup storage from any application? Something like a specialized database? From wmorgan-sup@masanjin.net Mon Jul 21 11:22:35 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 21 Jul 2008 08:22:35 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> Message-ID: <1216653716-sup-7355@entry> Reformatted excerpts from Peter Krenn's message of 2008-07-21: > What kind of interface will this service provide? Or will it be more > like a library which one could use to access the sup storage from any > application? Something like a specialized database? It will be a network service with Thrift defining the interface. -- William From steve@patter.mine.nu Mon Jul 21 11:26:59 2008 From: steve@patter.mine.nu (Stephen Patterson) Date: Mon, 21 Jul 2008 16:26:59 +0100 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216653716-sup-7355@entry> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> Message-ID: <20080721152658.GA23270@patter.mine.nu> On 21 Jul 08, William Morgan (wmorgan-sup at masanjin.net) wrote: > Reformatted excerpts from Peter Krenn's message of 2008-07-21: > > What kind of interface will this service provide? Or will it be more > > like a library which one could use to access the sup storage from any > > application? Something like a specialized database? > > It will be a network service with Thrift defining the interface. So we'd then need a collection of custom client applications to search and/or browse the index? This sounds quite a bit like the beagle project - http://beagle-project.org/Main_Page -- Stephen Patterson :: steve at patter.mine.nu :: http://patter.mine.nu/ GPG: B416F0DE :: Jabber: patter at jabber.earth.li "Don't be silly, Minnie. Who'd be walking round these cliffs with a gas oven?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From johnbent@lanl.gov Mon Jul 21 12:04:33 2008 From: johnbent@lanl.gov (John Bent) Date: Mon, 21 Jul 2008 10:04:33 -0600 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <20080721152658.GA23270@patter.mine.nu> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> <20080721152658.GA23270@patter.mine.nu> Message-ID: <1216656194-sup-755@tangerine.lanl.gov> Excerpts from Stephen Patterson's message of Mon Jul 21 09:26:59 -0600 2008: > On 21 Jul 08, William Morgan (wmorgan-sup at masanjin.net) wrote: > > Reformatted excerpts from Peter Krenn's message of 2008-07-21: > > > What kind of interface will this service provide? Or will it be more > > > like a library which one could use to access the sup storage from any > > > application? Something like a specialized database? > > > > It will be a network service with Thrift defining the interface. > > So we'd then need a collection of custom client applications to search > and/or browse the index? > > This sounds quite a bit like the beagle project - > http://beagle-project.org/Main_Page > And google desktop: http://desktop.google.com And spotlight: http://en.wikipedia.org/wiki/Spotlight_(software) And MS Fast Find: http://support.microsoft.com/support/kb/articles/Q166/3/02.ASP There is room for improvement in all of these tools but the margin seems considerably smaller than it did for the sup email client which is vastly superior to anything else. John From white.magic@gmx.de Mon Jul 21 14:43:49 2008 From: white.magic@gmx.de (Lionel Ott) Date: Mon, 21 Jul 2008 20:43:49 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216589569-sup-1520@entry> References: <1216589569-sup-1520@entry> Message-ID: <1216665560-sup-7096@Hel> Excerpts from William Morgan's message of Sun Jul 20 23:33:24 +0200 2008: > In which the new version of Sup is described! > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html Sounds nice overall but something I couldn't infer from the post was if you're thinking about doing just the reading and searching part of sup or if some of the mail functionality is going to be kept. Basically will sts be able to send mail or would one have to send it using some other client and sts then would present all that nicely to one, given you feed it with your mails. From wmorgan-sup@masanjin.net Mon Jul 21 22:12:09 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 21 Jul 2008 19:12:09 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <20080721152658.GA23270@patter.mine.nu> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> <20080721152658.GA23270@patter.mine.nu> Message-ID: <1216692061-sup-3543@entry> Reformatted excerpts from Stephen Patterson's message of 2008-07-21: > So we'd then need a collection of custom client applications to search > and/or browse the index? > > This sounds quite a bit like the beagle project - > http://beagle-project.org/Main_Page Thanks for the pointer. It does sound quite similar. Having played with Beagle a bit, I think they key difference is that I'm envisioning STS as being the primary interface to your precious infos, whereas Beagle seems more of a supplemental index of data that's primarily handled by other apps. This has a couple implications, including who's responsible for storing the files (STS: STS; Beagle: you and your apps), and what the user experience looks like (Beagle: use Thunderbird, then call up Beagle for help; STS: browse everything through your client, starting with a search for label "inbox", and call up other applications for handling foreign mime types). If anything, Beagle is closer to Sup classic, and STS brings us closer to Gmail. -- William From rgh@roughage.com.au Wed Jul 23 04:45:06 2008 From: rgh@roughage.com.au (Richard Heycock) Date: Wed, 23 Jul 2008 18:45:06 +1000 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216589569-sup-1520@entry> References: <1216589569-sup-1520@entry> Message-ID: <1216802131-sup-4710@wrasse> Excerpts from William Morgan's message of Mon Jul 21 07:33:24 +1000 2008: > In which the new version of Sup is described! > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html I really like the idea and I have to say that I'm *very* glad that you are keeping the ncurses interface. My one concern is that you are thinking of using Sphinx and as a consequence you are relient on a relational database. Is that really what you want for a mail client? I find this disturbing on two levels: having a full blown database system for email seems like overkill and the idea of an index bring based on a relational model quite appaling. There are a number of other indexs such as Xapian or Hyper Estraier both have ruby bindings and both are quite mature and widely used in other projects. Just my two cents. rgh -- +61 (0) 410 646 369 [e]: rgh at neoss.com.au [im]: rgh at jabber.org You're worried criminals will continue to penetrate into cyberspace, and I'm worried complexity, poor design and mismanagement will be there to meet them - Marcus Ranum From nicolas.pouillard@gmail.com Wed Jul 23 04:58:10 2008 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 23 Jul 2008 10:58:10 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216802131-sup-4710@wrasse> References: <1216589569-sup-1520@entry> <1216802131-sup-4710@wrasse> Message-ID: <1216803452-sup-8333@port-ext16.ensta.fr> Excerpts from Richard Heycock's message of Wed Jul 23 10:45:06 +0200 2008: > Excerpts from William Morgan's message of Mon Jul 21 07:33:24 +1000 2008: > > In which the new version of Sup is described! > > > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html > > I really like the idea and I have to say that I'm *very* glad that you > are keeping the ncurses interface. > > My one concern is that you are thinking of using Sphinx and as a > consequence you are relient on a relational database. Is that really > what you want for a mail client? I find this disturbing on two levels: > having a full blown database system for email seems like overkill and > the idea of an index bring based on a relational model quite appaling. > > There are a number of other indexs such as Xapian or Hyper Estraier > both have ruby bindings and both are quite mature and widely used in > other projects. I'm also concerned by using relying on relational databases for a mail service. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From terence.namusonge@gmail.com Wed Jul 23 05:27:46 2008 From: terence.namusonge@gmail.com (teroz) Date: Wed, 23 Jul 2008 11:27:46 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216803452-sup-8333@port-ext16.ensta.fr> References: <1216589569-sup-1520@entry> <1216802131-sup-4710@wrasse> <1216803452-sup-8333@port-ext16.ensta.fr> Message-ID: <1f7abd640807230227v75c28a62v6c299242a9bf3303@mail.gmail.com> Well surely if we r eschewing typical mail storage formats like mbox and IMAP then a database is the way to go unless your suggesting we write some form of storage library as well. On Wed, Jul 23, 2008 at 10:58 AM, Nicolas Pouillard < nicolas.pouillard at gmail.com> wrote: > Excerpts from Richard Heycock's message of Wed Jul 23 10:45:06 +0200 2008: > > Excerpts from William Morgan's message of Mon Jul 21 07:33:24 +1000 2008: > > > In which the new version of Sup is described! > > > > > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html > > > > I really like the idea and I have to say that I'm *very* glad that you > > are keeping the ncurses interface. > > > > My one concern is that you are thinking of using Sphinx and as a > > consequence you are relient on a relational database. Is that really > > what you want for a mail client? I find this disturbing on two levels: > > having a full blown database system for email seems like overkill and > > the idea of an index bring based on a relational model quite appaling. > > > > There are a number of other indexs such as Xapian or Hyper Estraier > > both have ruby bindings and both are quite mature and widely used in > > other projects. > > I'm also concerned by using relying on relational databases for a mail > service. > > -- > Nicolas Pouillard aka Ertai > > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > > -- --Teroz -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmorgan-sup@masanjin.net Wed Jul 23 13:09:35 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 23 Jul 2008 10:09:35 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216802131-sup-4710@wrasse> References: <1216589569-sup-1520@entry> <1216802131-sup-4710@wrasse> Message-ID: <1216832349-sup-2908@entry> Reformatted excerpts from Richard Heycock's message of 2008-07-23: > My one concern is that you are thinking of using Sphinx and as a > consequence you are relient on a relational database. Is that really > what you want for a mail client? I find this disturbing on two levels: > having a full blown database system for email seems like overkill and > the idea of an index bring based on a relational model quite appaling. I feel exactly the same way. I'm using Sphinx's XML interface to add things to the index, so there's no RDBMS involved. I hate XML but not as much as I hate RDBMS. The current plan is to actually store email/documents in some kind of persistent key-value store. I have a preliminary very simple implementation that just uses files on disk, but it will be possible to swap that out to something like TokyoCabinet or AWS. > There are a number of other indexs such as Xapian or Hyper Estraier > both have ruby bindings and both are quite mature and widely used in > other projects. Interesting. I will check those out. I only picked Sphinx because it seemed popular and robust, but it is currently making my life more difficult than it really needs to be. -- William From nicolas.pouillard@gmail.com Wed Jul 23 13:40:35 2008 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 23 Jul 2008 19:40:35 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216692061-sup-3543@entry> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> <20080721152658.GA23270@patter.mine.nu> <1216692061-sup-3543@entry> Message-ID: <1216834375-sup-1899@ausone.local> Excerpts from William Morgan's message of Tue Jul 22 04:12:09 +0200 2008: > Reformatted excerpts from Stephen Patterson's message of 2008-07-21: > > So we'd then need a collection of custom client applications to search > > and/or browse the index? > > > > This sounds quite a bit like the beagle project - > > http://beagle-project.org/Main_Page > > Thanks for the pointer. It does sound quite similar. Having played with > Beagle a bit, I think they key difference is that I'm envisioning STS as > being the primary interface to your precious infos, whereas Beagle seems > more of a supplemental index of data that's primarily handled by other > apps. > > This has a couple implications, including who's responsible for storing > the files (STS: STS; Beagle: you and your apps), and what the user > experience looks like (Beagle: use Thunderbird, then call up Beagle for > help; STS: browse everything through your client, starting with a > search for label "inbox", and call up other applications for handling > foreign mime types). > > If anything, Beagle is closer to Sup classic, and STS brings us closer > to Gmail. Another design choice, that could (and perhaps *should*) be made; is that stored data don't change in the case of mails, IM..., only their labels and children (threading) do. Then, this makes even more differences, general file system indexers have an harder task since, files change all the time this imply more complex data structures that often provides worse complexity than one could wish. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From rgh@roughage.com.au Wed Jul 23 17:41:52 2008 From: rgh@roughage.com.au (Richard Heycock) Date: Thu, 24 Jul 2008 07:41:52 +1000 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1f7abd640807230227v75c28a62v6c299242a9bf3303@mail.gmail.com> References: <1216589569-sup-1520@entry> <1216802131-sup-4710@wrasse> <1216803452-sup-8333@port-ext16.ensta.fr> <1f7abd640807230227v75c28a62v6c299242a9bf3303@mail.gmail.com> Message-ID: <1216848517-sup-4046@wrasse> Excerpts from terence.namusonge's message of Wed Jul 23 19:27:46 +1000 2008: > Well surely if we r eschewing typical mail storage formats like mbox and > IMAP then a database is the way to go > unless your suggesting we write some form of storage library as well. Two things: I do not have a problem with a database per se, I do however have a problem with a standalone relational database. There are many embedded databases that work a treat and the user never need know about them. That's pretty much what mbox, Maildir, etc are. The other point is that in using Sphinx the STS would not be using the database directly but would require it simply because the index required it. As I mentioned in my previous email there are a number of other indexes which will serve the purpose without the unnecessary complexity of a standalone database system. rgh > On Wed, Jul 23, 2008 at 10:58 AM, Nicolas Pouillard < > nicolas.pouillard at gmail.com> wrote: > > > Excerpts from Richard Heycock's message of Wed Jul 23 10:45:06 +0200 2008: > > > Excerpts from William Morgan's message of Mon Jul 21 07:33:24 +1000 2008: > > > > In which the new version of Sup is described! > > > > > > > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html > > > > > > I really like the idea and I have to say that I'm *very* glad that you > > > are keeping the ncurses interface. > > > > > > My one concern is that you are thinking of using Sphinx and as a > > > consequence you are relient on a relational database. Is that really > > > what you want for a mail client? I find this disturbing on two levels: > > > having a full blown database system for email seems like overkill and > > > the idea of an index bring based on a relational model quite appaling. > > > > > > There are a number of other indexs such as Xapian or Hyper Estraier > > > both have ruby bindings and both are quite mature and widely used in > > > other projects. > > > > I'm also concerned by using relying on relational databases for a mail > > service. > > > > -- > > Nicolas Pouillard aka Ertai > > > > _______________________________________________ > > sup-talk mailing list > > sup-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/sup-talk > > > > > -- +61 (0) 410 646 369 [e]: rgh at neoss.com.au [im]: rgh at jabber.org You're worried criminals will continue to penetrate into cyberspace, and I'm worried complexity, poor design and mismanagement will be there to meet them - Marcus Ranum From wmorgan-sup@masanjin.net Wed Jul 23 18:26:18 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 23 Jul 2008 15:26:18 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216834375-sup-1899@ausone.local> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> <20080721152658.GA23270@patter.mine.nu> <1216692061-sup-3543@entry> <1216834375-sup-1899@ausone.local> Message-ID: <1216850710-sup-6364@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-07-23: > Another design choice, that could (and perhaps *should*) be made; is > that stored data don't change in the case of mails, IM..., only their > labels and children (threading) do. I think that's a true fact. Draft messages are sort of an exception, but editing can always be simulated as deleting the old one and adding the new one. -- William From 5srmspw02@sneakemail.com Thu Jul 24 00:55:38 2008 From: 5srmspw02@sneakemail.com (Guarded Identity) Date: Wed, 23 Jul 2008 23:55:38 -0500 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216589569-sup-1520@entry> References: <1216589569-sup-1520@entry> Message-ID: <18084-90829@sneakemail.com> Excerpts from wmorgan-sup-at-masanjin.net wmorgan-sup-at-masanjin.net |Sup_Talk|'s message of Sun Jul 20 16:33:24 -0500 2008: > In which the new version of Sup is described! > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html Your first blog was intriguing, but this second one is putting Sup in a direction I'm really happy with. I'm happy about: Central Server -------------- I like having a central server, so I can run clients from multiple locations. Modifiable Messages ------------------- There was a post I read in this thread indicating that people didn't want to modify documents. But if we handle this as a "delete/re-add" operation, I'm hoping it will be fine. In all honesty, the modifications I'd like to do are - remove attachments. Sometimes at work, people send out some absolutely useless, gigantic attachments. - delete/expire documents. Documents Beyond E-mail ----------------------- I'm /really/ interested in storing different types of "documents" like RSS. . . maybe newsgroups too? Then I could stop using snownews and slrn. One client. . . actually, for this reason, I'd tried out Emacs Gnus, but I wasn't really happy with the experience/complexity. However, I was hoping to see if I could get in a request while you're in the beginning stages of STS development. True Thread-level Labels ------------------------ I was using rss2email, so the number of messages I had was enormous (although I disabled that due to performance problems, Ferret corruption, and the problem I'm discussion here). I hate wasting disk space needlessly, or cluttering the index for that matter. There's some mailing lists that are mostly fluff, but I wanted to save the occasional thread and expire the rest. But because messages attach to messages really, and not to the thread, negation in search logic breaks. If I search for threads that have "!label:save" I can get threads that have "save" messages if they also have a message not labeled "save". Attaching labels to message always bothered me. I'm hoping that with STS, you can consider designing an architecture that lets you attach labels to a thread grouping. I'm hoping it can be done in a way that's not too terribly performing. While I'm at it, I also have a feature request for STC (Sup The Client) Improved Multiple-Label Support ------------------------------- If I'm only using one label for each thread, then really there's no benefit to having labels over folders. So to really get the benefit of labels, it would be nice to be able to attach more than one of them in a more convenient way. There's a couple of ideas I had on how to do this: Label Hierarchies ----------------- if you use one label, it automatically pulls in another. But I wasn't sure how to manage this with the Sup UI. Label Recommendations --------------------- When using tab-complete for labeling, I see all my labels initially. By now, it's an overwhelming list, and I have to hunt for the label I really wanted. What would be nice is if Sup keeps an index of all label combinations (and perhaps their frequencies). Then when one hits tab the first time only labels that are relevant are presented. If those aren't adequate, then one might hit tab to cycle to a listing including the rest of the labels. Or perhaps without cycling, all labels can be listed by frequency; that way, the hunt for the most relevant label won't be so bad. So Sup probably didn't have this kind of feature because of the stronger advocacy for: - automated label attachment with hooks - not relying on labels as much as one relies on the search engine for keyword queries (the GMail way) But at work, people send me too many messages with too many different types of contexts. It would take quite a bit of AI to auto-categorize these messages. Keyword searches are maybe okay for some of these messages, but it's not really perfect. Sometimes I have to run through synonyms for certain concepts. Better label management would really help me at work. Okay, so those are the requests I have thus far. Hopefully they aren't too far off base from what you are interested in doing with Sup/STS. I'm happy to talk through concepts on this list. And although I'm still working up my Ruby skills, I'm happy to try to contribute code. By the way, are you set up to get these kinds of feature requests with ditz? I didn't see a ditz "bugs" database (folder) in my git clone of Sup. Or are you just using ditz internally for your own personal tracking of Sup development? Seems like there's a number of places to issue feature requests: - this mailing list - ditz, if you can help me figure out how best to use it - a FeatureRequest wiki page, but it would be moot if you didn't make a habit of looking at it Just let us know what you prefer. -Sukant From nicolas.pouillard@gmail.com Thu Jul 24 05:16:45 2008 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 24 Jul 2008 11:16:45 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216850710-sup-6364@entry> References: <1216589569-sup-1520@entry> <575d86ad0807210514n573972ecr2feb7aafcb9679e1@mail.gmail.com> <1216653716-sup-7355@entry> <20080721152658.GA23270@patter.mine.nu> <1216692061-sup-3543@entry> <1216834375-sup-1899@ausone.local> <1216850710-sup-6364@entry> Message-ID: <1216890970-sup-1179@ausone.inria.fr> Excerpts from William Morgan's message of Thu Jul 24 00:26:18 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-07-23: > > Another design choice, that could (and perhaps *should*) be made; is > > that stored data don't change in the case of mails, IM..., only their > > labels and children (threading) do. > > I think that's a true fact. Draft messages are sort of an exception, but > editing can always be simulated as deleting the old one and adding the > new one. Perhaps that drafts should be marked as "short-lived", and left in another store. This reminds me how generational Garbage Collectors works, there is a kind of relation... -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard@gmail.com Thu Jul 24 05:21:28 2008 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 24 Jul 2008 11:21:28 +0200 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <18084-90829@sneakemail.com> References: <1216589569-sup-1520@entry> <18084-90829@sneakemail.com> Message-ID: <1216891009-sup-9628@ausone.inria.fr> Excerpts from Guarded Identity's message of Thu Jul 24 06:55:38 +0200 2008: > Excerpts from wmorgan-sup-at-masanjin.net wmorgan-sup-at-masanjin.net |Sup_Talk|'s message of Sun Jul 20 16:33:24 -0500 2008: > > In which the new version of Sup is described! > > > > http://all-thing.net/2008/07/rethinking-sup-part-ii.html > > Your first blog was intriguing, but this second one is putting Sup in a > direction I'm really happy with. I'm happy about: > > Central Server > -------------- > I like having a central server, so I can run clients from multiple > locations. > > Modifiable Messages > ------------------- > There was a post I read in this thread indicating that people didn't want > to modify documents. But if we handle this as a "delete/re-add" > operation, I'm hoping it will be fine. > > In all honesty, the modifications I'd like to do are > > - remove attachments. Sometimes at work, people send out some > absolutely useless, gigantic attachments. > > - delete/expire documents. > > Documents Beyond E-mail > ----------------------- > I'm /really/ interested in storing different types of "documents" like RSS. > . . maybe newsgroups too? Then I could stop using snownews and slrn. One > client. . . actually, for this reason, I'd tried out Emacs Gnus, but I > wasn't really happy with the experience/complexity. > > However, I was hoping to see if I could get in a request while you're in the > beginning stages of STS development. > > True Thread-level Labels > ------------------------ Here is another big design decision, note that some labels are truly message based: * unread: of course * spam: to be sure that a spam message a response to a ham message don't throw away the whole thread. * starred: sometime it's there to highlight a message and sometimes to select the whole thread. And some others are truly thread based: * inbox * most of users labels * killed Since there is mandatory requirements for message based labels and thread based labels, one can provide both. Perhaps a syntactic distinction would be sufficient: * a case distinction: INBOX vs unread * a special mark: inbox* vs unread (here the star means the repetition on all messages of the thread). * more ideas to find... > I was using rss2email, so the number of messages I had was enormous > (although I disabled that due to performance problems, Ferret corruption, > and the problem I'm discussion here). I hate wasting disk space > needlessly, or cluttering the index for that matter. There's some mailing > lists that are mostly fluff, but I wanted to save the occasional thread and > expire the rest. But because messages attach to messages really, and not > to the thread, negation in search logic breaks. If I search for threads > that have "!label:save" I can get threads that have "save" messages if they > also have a message not labeled "save". > > Attaching labels to message always bothered me. I'm hoping that with STS, > you can consider designing an architecture that lets you attach labels to a > thread grouping. I'm hoping it can be done in a way that's not too > terribly performing. > > While I'm at it, I also have a feature request for STC (Sup The Client) > > Improved Multiple-Label Support > ------------------------------- > If I'm only using one label for each thread, then really there's no benefit > to having labels over folders. So to really get the benefit of labels, it > would be nice to be able to attach more than one of them in a more > convenient way. > > There's a couple of ideas I had on how to do this: > > Label Hierarchies > ----------------- > if you use one label, it automatically pulls in another. But I wasn't > sure how to manage this with the Sup UI. > > Label Recommendations > --------------------- > When using tab-complete for labeling, I see all my labels initially. > By now, it's an overwhelming list, and I have to hunt for the label I > really wanted. What would be nice is if Sup keeps an index of all > label combinations (and perhaps their frequencies). Then when one hits > tab the first time only labels that are relevant are presented. If > those aren't adequate, then one might hit tab to cycle to a listing > including the rest of the labels. Or perhaps without cycling, all > labels can be listed by frequency; that way, the hunt for the most > relevant label won't be so bad. Hum, that's a very interesting feature. This reminds me delicio.us. In the same line, be able to share popular/public labels for discussion could be very nice. Let's imagine that public tagging is done using public:foo labels, users could share some labels using public ones. Then in answer message an X-Public-Labels header is added and then suggested to users when applying labels. > > So Sup probably didn't have this kind of feature because of the stronger > advocacy for: > > - automated label attachment with hooks > > - not relying on labels as much as one relies on the search engine for > keyword queries (the GMail way) > > But at work, people send me too many messages with too many different types > of contexts. It would take quite a bit of AI to auto-categorize these > messages. Keyword searches are maybe okay for some of these messages, but > it's not really perfect. Sometimes I have to run through synonyms for > certain concepts. Better label management would really help me at work. > > Okay, so those are the requests I have thus far. Hopefully they aren't too > far off base from what you are interested in doing with Sup/STS. I'm happy to > talk through concepts on this list. And although I'm still working up my Ruby > skills, I'm happy to try to contribute code. > > By the way, are you set up to get these kinds of feature requests with ditz? I > didn't see a ditz "bugs" database (folder) in my git clone of Sup. Or are you > just using ditz internally for your own personal tracking of Sup development? It's in the bugs branch. > > Seems like there's a number of places to issue feature requests: > > - this mailing list > > - ditz, if you can help me figure out how best to use it > > - a FeatureRequest wiki page, but it would be moot if you didn't make a > habit of looking at it > > Just let us know what you prefer. I'm not William but I would say that the mailing list is the preferred way. Moreover attaching a git-patch for the ditz issue tracker could help. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Fri Jul 25 03:18:14 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 25 Jul 2008 00:18:14 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <18084-90829@sneakemail.com> References: <1216589569-sup-1520@entry> <18084-90829@sneakemail.com> Message-ID: <1216967875-sup-4048@entry> Reformatted excerpts from Guarded Identity's message of 2008-07-23: > In all honesty, the modifications I'd like to do are > > - remove attachments. Sometimes at work, people send out some > absolutely useless, gigantic attachments. > > - delete/expire documents. Sup 2.0 will definitely handle both of these cases. > I'm /really/ interested in storing different types of "documents" like > RSS. . . maybe newsgroups too? Sure. Anything you can munge into Sup's expected format will be supported. I'm expecting, in addition to a variety of clients (well if other people get excited!), a variety of readers, each of which understands some how to get and import into Sup some kind of information. > There's some mailing lists that are mostly fluff, but I wanted to save > the occasional thread and expire the rest. But because messages > attach to messages really, and not to the thread, negation in search > logic breaks. If I search for threads that have "!label:save" I can > get threads that have "save" messages if they also have a message not > labeled "save". The problem here is not really that there are labels on messages, it's that the current search operation is: for each message that matches the query, return the thread that contains it. That works for positive searches, but clearly doesn't work for negative ones. Making negative search efficient is hard. But I don't think it matters whether the labels are per-message or per-thread... > Attaching labels to message always bothered me. How come? Every other property of a thread is calculated from its component messages---subject, recipients, date---so why not the labels as well? It's a nice symmetry. Anyways, I'm not sure what the right answer is yet. It certainly could be per-thread labels. > Label Hierarchies > ----------------- > if you use one label, it automatically pulls in another. But I wasn't > sure how to manage this with the Sup UI. It would be doable... probably through a hook. > When using tab-complete for labeling, I see all my labels initially. > By now, it's an overwhelming list, and I have to hunt for the label I > really wanted. What would be nice is if Sup keeps an index of all > label combinations (and perhaps their frequencies). Then when one > hits tab the first time only labels that are relevant are presented. > If those aren't adequate, then one might hit tab to cycle to a listing > including the rest of the labels. Or perhaps without cycling, all > labels can be listed by frequency; that way, the hunt for the most > relevant label won't be so bad. The last of those options (list all but by frequency) is definitely doable. The other options are probably a fair amount of work. You can play around with LabelSearchMode and LabelManager if you want to try and mock something up. I don't expect those to change too much, except that LabelManager will probably become a thin shell talking to the server. > By the way, are you set up to get these kinds of feature requests with > ditz? I didn't see a ditz "bugs" database (folder) in my git clone of > Sup. Or are you just using ditz internally for your own personal > tracking of Sup development? As Nicolas pointed out, it's currently on the bugs branch, but I'm planning to move it back into master and starting to add issues there. I also have tentative plans to move Sup's git repo over to gitorious so that people can see pretty pictures when they clone. > Seems like there's a number of places to issue feature requests: > - this mailing list > - ditz, if you can help me figure out how best to use it > - a FeatureRequest wiki page, but it would be moot if you didn't make a > habit of looking at it > > Just let us know what you prefer. The mailing list, ditz patches, or ditz merge requests are all perfectly acceptable. -- William From marcus-sup@bar-coded.net Fri Jul 25 08:11:06 2008 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Fri, 25 Jul 2008 13:11:06 +0100 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216832349-sup-2908@entry> References: <1216589569-sup-1520@entry> <1216802131-sup-4710@wrasse> <1216832349-sup-2908@entry> Message-ID: <1216987703-sup-5083@tomsk> On 23.7.2008, William Morgan wrote: > > There are a number of other indexs such as Xapian or Hyper Estraier > > both have ruby bindings and both are quite mature and widely used in > > other projects. > > Interesting. I will check those out. I only picked Sphinx because it > seemed popular and robust, but it is currently making my life more difficult > than it really needs to be. You might enjoy datamapper - http://datamapper.org I've been knocking up web apps in ruby/sinatra/datamapper in stupidly few lines with absolutely no contact with the db underlying the system other than through datamapper. Marcus From wmorgan-sup@masanjin.net Fri Jul 25 12:00:40 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 25 Jul 2008 09:00:40 -0700 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1216891009-sup-9628@ausone.inria.fr> References: <1216589569-sup-1520@entry> <18084-90829@sneakemail.com> <1216891009-sup-9628@ausone.inria.fr> Message-ID: <1217001070-sup-9401@entry> Reformatted excerpts from nicolas.pouillard's message of 2008-07-24: > Here is another big design decision, note that some labels are truly > message based: > > * unread: of course > * spam: to be sure that a spam message a response to a ham message > don't throw away the whole thread. > * starred: sometime it's there to highlight a message and sometimes > to select the whole thread. What's interesting about the labels you've listed is that they all have special semantics, i.e. the server or the client does something special based on whether they're present. Do people have "user" labels that they use to distinguish individual messages, as opposed to individual threads? If not, we could have labels only on threads by having a bunch of boolean flags on messages: read/unread, spam/ham, starred/regular, draft/not-draft, etc. The search syntax would probably change for those features. > Since there is mandatory requirements for message based labels > and thread based labels, one can provide both. Perhaps a syntactic > distinction would be sufficient: > * a case distinction: INBOX vs unread > * a special mark: inbox* vs unread (here the star means the > repetition on all messages of the thread). Having both would be possible too, but it seems overly complicated to me. I think that's my least favorite option right now. This is a good discussion though. I haven't really thought this all through. -- William From 5srmspw02@sneakemail.com Sat Jul 26 03:32:17 2008 From: 5srmspw02@sneakemail.com (Guarded Identity) Date: Sat, 26 Jul 2008 02:32:17 -0500 Subject: [sup-talk] rethinking sup part ii In-Reply-To: <1217001070-sup-9401@entry> References: <1216589569-sup-1520@entry> <18084-90829@sneakemail.com> <1216891009-sup-9628@ausone.inria.fr> <1217001070-sup-9401@entry> Message-ID: <14658-35025@sneakemail.com> Excerpts from William Morgan's message of Fri Jul 25 11:00:40 -0500 2008: > > Reformatted excerpts from nicolas.pouillard's message of 2008-07-24: > > > Here is another big design decision, note that some labels are truly > > message based: > > > > * unread: of course > > * spam: to be sure that a spam message a response to a ham message > > don't throw away the whole thread. > > * starred: sometime it's there to highlight a message and sometimes > > to select the whole thread. > > What's interesting about the labels you've listed is that they all have > special semantics, i.e. the server or the client does something special > based on whether they're present. > > Do people have "user" labels that they use to distinguish individual > messages, as opposed to individual threads? I got away with applying the "spam" label at the thread level because I never get any spam that's actually part of a thread; it's normally just a stand-alone piece of mail. I'm not sure what other people use starring for, but I just use it to highlight things I need to reply to, and for that purpose, it works fine at a thread-level because most threads only have one response I'm interested in issuing. But I guess I've seen some of those gigantic threads, so maybe starring at the message-level /might/ be useful, but I'd not sweat it if it wasn't possible. Even for "unread", I get away just managing it at the thread-level, because I'm generally marking an entire thread as read. However, I'd imagine someone might want to revert the unread status of part of a thread. However, that would be a nightmare for a large thread. In that case, I'd probably just use the "@" key-binding to revert labels. So all in all, I never use message-level labels, even though I get understand the instance in which they're needed. The major reason for this is that the presentation of the search is at the thread level, so it makes little sense to think of labels at the message level. > If not, we could have labels only on threads by having a bunch of > boolean flags on messages: read/unread, spam/ham, starred/regular, > draft/not-draft, etc. The search syntax would probably change for those > features. This is /exactly/ what I'm hoping for. I could probably come up with other hypothetical abstractions for indexing, but I'm happy as long as at the end of the day I get negation in reasonably fast searches. I know it sounds like a feature that not everyone might use, but the more messages I put in the index, the more I find I myself trying to make use of negation to prune searches. Also, sometimes I like to manage Sup with scripts and having negation allows me to do some more cool things without having to bother William with feature requests for the odd message/label-managing tasks I have. Hopefully you can continue brain-storming what design you want to do to support this. If you run into a problem, maybe we can jump into the design then. > > Since there is mandatory requirements for message based labels > > and thread based labels, one can provide both. Perhaps a syntactic > > distinction would be sufficient: > > * a case distinction: INBOX vs unread > > * a special mark: inbox* vs unread (here the star means the > > repetition on all messages of the thread). > > Having both would be possible too, but it seems overly complicated to > me. I think that's my least favorite option right now. Yeah, I was trying to think of a way to manage both, and it felt like a kludge. Personally, I like the idea of managing as much as we can at the thread-level. -Sukant From matt.fowles@gmail.com Mon Jul 28 11:04:04 2008 From: matt.fowles@gmail.com (Matt Fowles) Date: Mon, 28 Jul 2008 11:04:04 -0400 Subject: [sup-talk] incrementally loading large messages Message-ID: All~ I have a feature request for sup which block my ability to use it in a work context. Extremely large emails, must download fully before being displayed at all. Unfortunately, my work emails out nightly test results which are so large that they can take minutes to load in sup. I would like it if sup showed the incrementally as it loaded. Also, does sup have a bug tracker where features can be submitted, because I have a preference to be able to file bugs that I find without being on the mailing list. Thanks, Matt From wmorgan-sup@masanjin.net Mon Jul 28 14:22:19 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 28 Jul 2008 11:22:19 -0700 Subject: [sup-talk] incrementally loading large messages In-Reply-To: References: Message-ID: <1217269028-sup-6714@entry> Reformatted excerpts from Matt Fowles's message of 2008-07-28: > I have a feature request for sup which block my ability to use it in a > work context. Extremely large emails, must download fully before > being displayed at all. Unfortunately, my work emails out nightly > test results which are so large that they can take minutes to load in > sup. I would like it if sup showed the incrementally as it loaded. Wow. That's a large email. This is a good time for such a feature request, because I'm in the middle of designing the Sup server protocol. Consider it added. > Also, does sup have a bug tracker where features can be submitted, > because I have a preference to be able to file bugs that I find > without being on the mailing list. Oh yes, it's very simple. Clone the Sup repo, add a ditz issue, and send a merge request to me. No mailing list usage required whatsoever. :) -- William From matt.fowles@gmail.com Mon Jul 28 15:03:13 2008 From: matt.fowles@gmail.com (Matt Fowles) Date: Mon, 28 Jul 2008 15:03:13 -0400 Subject: [sup-talk] incrementally loading large messages In-Reply-To: <1217269028-sup-6714@entry> References: <1217269028-sup-6714@entry> Message-ID: William~ On Mon, Jul 28, 2008 at 2:22 PM, William Morgan wrote: > Reformatted excerpts from Matt Fowles's message of 2008-07-28: >> I have a feature request for sup which block my ability to use it in a >> work context. Extremely large emails, must download fully before >> being displayed at all. Unfortunately, my work emails out nightly >> test results which are so large that they can take minutes to load in >> sup. I would like it if sup showed the incrementally as it loaded. > > Wow. That's a large email. Yeah, it is 5.3 MB. > This is a good time for such a feature request, because I'm in the > middle of designing the Sup server protocol. Consider it added. > >> Also, does sup have a bug tracker where features can be submitted, >> because I have a preference to be able to file bugs that I find >> without being on the mailing list. > > Oh yes, it's very simple. Clone the Sup repo, add a ditz issue, and send > a merge request to me. No mailing list usage required whatsoever. :) Is there no web interface? Perhaps, that is a ditz feature request... Matt From wmorgan-sup@masanjin.net Wed Jul 30 22:10:49 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Jul 2008 19:10:49 -0700 Subject: [sup-talk] sup news (including 0.6 release) Message-ID: <1217466178-sup-1370@entry> Hi all, Some news: - I've moved Sup over to Gitorious. I don't know that this will magically spur a continuous stream of bugfixes, but at least now we have a repo webpage that's not broken. If you're running from Git, you should update your repo to pull from there. If you don't have local changes, you can simply reclone it: git clone git://gitorious.org/sup/mainline.git If you want to preserve your local repository, you can do something like: git remote add gitorious git://gitorious.org/sup/mainline.git git fetch Then for each branch that you want "git pull" to pull from gitorious, you'll need to do: git config branch..remote gitorious git config branch..merge refs/heads/ and then check it out and try pulling. If you haven't made any commits, this should be a fast-forward. If you want to call the remote "origin" instead of "gitorious", you'll just have to remove or rename your origin remote first. The commands above will be the same. Note that I've reset the "next" branch, so if you have commits on that branch, life may be little more complicated. Doing the above and merging should work. Or you can isolate your changes somehow and rebase --onto, if you feel like being complicated. - I've merged all outstanding topic branches down to master, and cherry-picked a couple commits that somehow ended up in next by themselves. So master should be the latest and greatest for the moment. - I've moved the bugs dir directly into master. The bugs branch is now deprecated. (It doesn't even exist in the Gitorious repo.) - I'm planning on release an 0.6 soon with all the bugfixes we have so far. To this end, I've unassigned all unclosed issues from the 0.6 release. - Can anyone confirm that that the master branch on gitorious works for you, just like the next branch did in the old repo? It should, but I want to double-check before I ship 0.6. That's it! Work continues on STS and I hope to have some kind of functional code to publish soon. -- William From johnbent@lanl.gov Wed Jul 30 22:22:30 2008 From: johnbent@lanl.gov (John Bent) Date: Wed, 30 Jul 2008 20:22:30 -0600 Subject: [sup-talk] sup news (including 0.6 release) In-Reply-To: <1217466178-sup-1370@entry> References: <1217466178-sup-1370@entry> Message-ID: <1217470901-sup-800@tangerine.lanl.gov> Excerpts from William Morgan's message of Wed Jul 30 20:10:49 -0600 2008: > If you don't have local changes, you can simply reclone it: > git clone git://gitorious.org/sup/mainline.git > This worked for me except I got an error message and had to install fastthread first. Thanks William and all for all your hard work on sup! John From rgh@roughage.com.au Thu Jul 31 02:38:05 2008 From: rgh@roughage.com.au (Richard Heycock) Date: Thu, 31 Jul 2008 16:38:05 +1000 Subject: [sup-talk] sup news (including 0.6 release) In-Reply-To: <1217466178-sup-1370@entry> References: <1217466178-sup-1370@entry> Message-ID: <1217486240-sup-679@wrasse> Excerpts from William Morgan's message of Thu Jul 31 12:10:49 +1000 2008: > Hi all, > > Some news: > > - I've moved Sup over to Gitorious. I don't know that this will > magically spur a continuous stream of bugfixes, but at least now we > have a repo webpage that's not broken. > > If you're running from Git, you should update your repo to pull from > there. > > If you don't have local changes, you can simply reclone it: > git clone git://gitorious.org/sup/mainline.git > > If you want to preserve your local repository, you can do something like: > git remote add gitorious git://gitorious.org/sup/mainline.git > git fetch > > Then for each branch that you want "git pull" to pull from gitorious, > you'll need to do: > git config branch..remote gitorious > git config branch..merge refs/heads/ > > and then check it out and try pulling. If you haven't made any > commits, this should be a fast-forward. > > If you want to call the remote "origin" instead of "gitorious", you'll > just have to remove or rename your origin remote first. The commands > above will be the same. > > Note that I've reset the "next" branch, so if you have commits on that > branch, life may be little more complicated. Doing the above and merging > should work. Or you can isolate your changes somehow and rebase > --onto, if you feel like being complicated. > > - I've merged all outstanding topic branches down to master, and > cherry-picked a couple commits that somehow ended up in next by > themselves. So master should be the latest and greatest for the > moment. > > - I've moved the bugs dir directly into master. The bugs branch is now > deprecated. (It doesn't even exist in the Gitorious repo.) > > - I'm planning on release an 0.6 soon with all the bugfixes we have so > far. To this end, I've unassigned all unclosed issues from the 0.6 > release. > > - Can anyone confirm that that the master branch on gitorious works for > you, just like the next branch did in the old repo? It should, but I > want to double-check before I ship 0.6. Works for me as well. rgh > > That's it! Work continues on STS and I hope to have some kind of > functional code to publish soon. -- +61 (0) 410 646 369 [e]: rgh at neoss.com.au [im]: rgh at jabber.org You're worried criminals will continue to penetrate into cyberspace, and I'm worried complexity, poor design and mismanagement will be there to meet them - Marcus Ranum From me@pekdon.net Thu Jul 31 03:14:26 2008 From: me@pekdon.net (Claes Nästén) Date: Thu, 31 Jul 2008 09:14:26 +0200 Subject: [sup-talk] sup news (including 0.6 release) In-Reply-To: <1217466178-sup-1370@entry> References: <1217466178-sup-1370@entry> Message-ID: <1217488425-sup-6633@hydrogen.lan> Excerpts from William Morgan's message of Thu Jul 31 04:10:49 +0200 2008: > > - Can anyone confirm that that the master branch on gitorious works for > you, just like the next branch did in the old repo? It should, but I > want to double-check before I ship 0.6. > Works for me as well after re-creating the next branch (didn't have anything to keep in it.) -- Claes N?st?n, , http://www.pekdon.net/ "Money has corrupted so much in this world, life would be meaningless if it kills music as well." - Bin?rpilot From wmorgan-sup@masanjin.net Thu Jul 31 18:40:52 2008 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 31 Jul 2008 15:40:52 -0700 Subject: [sup-talk] sup news (including 0.6 release) In-Reply-To: <1217488425-sup-6633@hydrogen.lan> References: <1217466178-sup-1370@entry> <1217488425-sup-6633@hydrogen.lan> Message-ID: <1217544036-sup-5850@entry> Reformatted excerpts from Claes N?st?n's message of 2008-07-31: > Works for me as well after re-creating the next branch (didn't have > anything to keep in it.) Thanks guys. I'm going to release an 0.6 soon. -- William From rgh@roughage.com.au Thu Jul 31 19:03:32 2008 From: rgh@roughage.com.au (Richard Heycock) Date: Fri, 01 Aug 2008 09:03:32 +1000 Subject: [sup-talk] colors in 0.6 Message-ID: <1217545348-sup-5151@wrasse> I'm trying out the 0.6 pre-release and tried to change my colours but what I've done doesn't work. I created a $HOME/.sup/colors.yaml like this: --- :colors: :index_new: :bg: yellow But it still comes up the default colour scheme. I know the file is being read (using strace) so I'm guessing it's a problem with the yaml. Any ideas? rgh -- +61 (0) 410 646 369 [e]: rgh at neoss.com.au [im]: rgh at jabber.org You're worried criminals will continue to penetrate into cyberspace, and I'm worried complexity, poor design and mismanagement will be there to meet them - Marcus Ranum