From: 5srmspw02@sneakemail.com (Guarded Identity)
Subject: [sup-talk] rethinking sup part ii
Date: Wed, 23 Jul 2008 23:55:38 -0500 [thread overview]
Message-ID: <18084-90829@sneakemail.com> (raw)
In-Reply-To: <1216589569-sup-1520@entry>
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
next prev parent reply other threads:[~2008-07-24 4:55 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 [this message]
2008-07-24 9:21 ` Nicolas Pouillard
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=18084-90829@sneakemail.com \
--to=5srmspw02@sneakemail.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