From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
Subject: [sup-talk] rethinking sup part ii
Date: Thu, 24 Jul 2008 11:21:28 +0200 [thread overview]
Message-ID: <1216891009-sup-9628@ausone.inria.fr> (raw)
In-Reply-To: <18084-90829@sneakemail.com>
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: <http://rubyforge.org/pipermail/sup-talk/attachments/20080724/598bc93c/attachment.bin>
next prev parent reply other threads:[~2008-07-24 9:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-20 21:33 William Morgan
2008-07-20 23:28 ` Guillaume Quintard
2008-07-21 0:04 ` William Morgan
2008-07-21 5:43 ` Guillaume Quintard
2008-07-21 12:14 ` Peter Krenn
2008-07-21 15:22 ` William Morgan
2008-07-21 15:26 ` Stephen Patterson
2008-07-21 16:04 ` John Bent
2008-07-22 2:12 ` William Morgan
2008-07-23 17:40 ` Nicolas Pouillard
2008-07-23 22:26 ` William Morgan
2008-07-24 9:16 ` Nicolas Pouillard
2008-07-21 18:43 ` Lionel Ott
2008-07-23 8:45 ` Richard Heycock
2008-07-23 8:58 ` Nicolas Pouillard
2008-07-23 9:27 ` teroz
2008-07-23 21:41 ` Richard Heycock
2008-07-23 17:09 ` William Morgan
2008-07-25 12:11 ` Marcus Williams
2008-07-24 4:55 ` Guarded Identity
2008-07-24 9:21 ` Nicolas Pouillard [this message]
2008-07-25 16:00 ` William Morgan
2008-07-26 7:32 ` Guarded Identity
2008-07-25 7:18 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1216891009-sup-9628@ausone.inria.fr \
--to=nicolas.pouillard@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox