Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] rethinking sup part ii
Date: Fri, 25 Jul 2008 00:18:14 -0700	[thread overview]
Message-ID: <1216967875-sup-4048@entry> (raw)
In-Reply-To: <18084-90829@sneakemail.com>

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 <wmorgan-sup at masanjin.net>


      parent reply	other threads:[~2008-07-25  7:18 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
2008-07-25 16:00     ` William Morgan
2008-07-26  7:32       ` Guarded Identity
2008-07-25  7:18   ` William Morgan [this message]

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=1216967875-sup-4048@entry \
    --to=wmorgan-sup@masanjin.net \
    /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