On Sun, Aug 24, 2008 at 5:30 PM, William Morgan
<[EMAIL PROTECTED]> wrote:
> Hi Barton,

"Bart" is fine.  I only display it the "long way" to stop people from
calling me "Bartholomew."

> My current focus is on the backend to Sup 2.0, but in general I'm happy
> to accept patches and merge requests to fix these issues.

Unfortunately I'm not much of a ruby programmer yet.  Practically
anything else for longer than I want to think about, but not ruby,
though I'm looking at it.

> Personally I don't like the idea of adding structure to labels, because
> this proposal (and others before it) are oriented at people with a lot
> of labels, and I suspect that too many labels is a symptom that you're
> doing something wrong.

It's an organizational thing.  Some people think better in hierarchy.
And occasionally one has as a message that relates closely to a
particular subject but doesn't mention any of the usual terms one
would search for, so it's handy to have a way to force a connection.

> That said, I know I'm crazy, and I would accept a patch that made this
> an (optional!) feature. One easy way might be to make it solely a UI
> tweak to LabelSearchMode, where any labels with a "/" in them are fit
> into a pre-collapsed hierarchy instead of displayed in a big list.

That's essentially what I was suggesting.

> I agree that better search expression help would be nice. Patches
> accepted. :)

Does anyone other than you really know what the help should say?

>> If you're going to have any hope of becoming the choice of nerds
>> everywhere, you've got address the "play well with others" problem, at
>> the very least with the IMAP INBOX, if not with other mailboxes.
>
> Actually, I'm going to be taking a very different tack in Sup 2.0, and
> not deal with IMAP at all. Sup will maintain its own document store, and
> it's going to be up to the user to insert your mail into it.

After reading your blog posts this was the one thing I really wanted
to comment on.

I think this is a mistake.  By all means separate the document index
from the viewer, but I'd advise against attempting to be the warehouse
for the data.  The most important thing needed to play nicely is to
gracefully handle the case of data going missing from the source;
sure, you can do that by always copying the data up front, but that's
a blunt instrument that destroys several of the other advantages of
the current sup.

My suggestion:  Separate the indexing and querying of the index from
the sources.  Make it the responsibility of the viewer component to
fetch the full documents from the sources and to fail gracefully when
a query returns a document that's no longer available.  Give the
viewer a hook so that with the appropriate plug-in, certain indexing
updates (like spam-tagging) can be pushed back to the source at the
same time.  (It's up to the plug-in to decide how.)

If you have that, you can still use your own document source into
which you dump everything.

> I know that's probably not the answer you want. But I have no desire to
> spend the requisite years of my life dealing with with hokey IMAP
> servers, Ruby's hokey IMAP libraries, and everything in between.

I'm not suggesting (or even encouraging) that sup become a
full-fledged IMAP client.
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk

Reply via email to