From mboxrd@z Thu Jan 1 00:00:00 1970 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 25 Jul 2008 00:18:14 -0700 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: <1216967875-sup-4048@entry> 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