From mboxrd@z Thu Jan 1 00:00:00 1970 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: