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