Subject: Re: [MORG] THREAD= search return option in draft-ietf-morg-inthread-01.txt

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 3 Aug 2010 12:18:34 +0200

On 07/28/2010 02:36 PM, Alexey Melnikov wrote:
> I think this is useful, as it affects outcome of an INTHREAD search.

Can you suggest some use cases?

> However section 3.3 is lacking any example. In particular, it is not
> clear if this option is going to result in an ESEARCH response.

It lacks an example because I can't think of a useful one.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 03 Aug 2010 18:14:34 +0200

> Can you suggest some use cases?
My understanding is that the parameter changes what is considered to be 
"in a thread"? If that is not the case, then I don't really understand 
why it is needed.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 4 Aug 2010 14:11:38 +0200

On 08/03/2010 06:14 PM, Alexey Melnikov wrote:
> "in a thread"?

Yes.

> If that is not the case, then I don't really understand
> why it is needed.

It is the case, and I can't find a reason to implement it. I know how to 
implement it, but not why to.

Consider: Either a client using THREAD=x has to derive x from a) user 
input, or from b) something else.

a) I can't imagine why anyone would waste dialog pixels on that (perhaps 
a failure of my imagination, feel free to improve on it). Remember that 
every checkbox is something the user has to look at when searching for 
something else: Extra UI features need to carry their load.

b) In that case, THREAD=x causes invisible client differences. IMO, if 
two user clients present semantically identical search dialogs, they 
should present the same result set too.

Overall, I think THREAD= is slightly negative. Only what's clearly 
positive is IMO worth implementing. So I want to drop it.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 05 Aug 2010 13:14:10 +0100

Hi Arnt,
Mostly playing devil's advocate below.

Arnt Gulbrandsen wrote:

> It is the case, and I can't find a reason to implement it. I know how 
> to implement it, but not why to.
>
> a) I can't imagine why anyone would waste dialog pixels on that 
> (perhaps a failure of my imagination, feel free to improve on it). 
> Remember that every checkbox is something the user has to look at when 
> searching for something else: Extra UI features need to carry their load.

I agree that this feature is quite hard to explain to users, so it 
shouldn't be exposed in UI.

> should present the same result set too.

I am not sure I am getting this. Presenting found messages in UI is not 
the only way to use SEARCH.
Let's imagine that a client wants to download all messages in a thread 
for offline use. Surely the set of messages considered "in the thread" 
will be different depending on threading mechanism used.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 5 Aug 2010 14:45:16 +0200

> the only way to use SEARCH.

True.

> will be different depending on threading mechanism used.

OK, consider that. I do something like that (that's I-as-user preseeding 
a cache) using INTHREAD OR YOUNGER 604800 UNSEEN. To my mind, that's 
just one of many good-enough approximations. The ideal is "what arnt 
will want", and the smallest algoritmically specified superset of that 
is ALL, which would occasionally be painful via UMTS.

Anyway, in my opinion any good approximation of "what arnt will want" is 
good enough. I could change YOUNGER 604800 to a different nubmer of 
days, or change UNSEEN to RECENT, or use a different threading 
algorithm, and the result should also be good enough. Not significantly 
different.

But this use case doesn't need lots of approximations, any one good 
approximation will do. Therefore this use case does not justify 
THREAD=x. IMO.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 05 Aug 2010 13:48:46 +0100

> positive is IMO worth implementing. So I want to drop it.

So do you want it to always use THREAD=REFS or whatever the server wants
to use? (What if we later figure out a much better THREAD=REFS2?)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 5 Aug 2010 14:55:31 +0200

On 08/05/2010 02:48 PM, Timo Sirainen wrote:
> to use?

Either would be fine with me. I have a preference, but I'd be happy with 
either.

> (What if we later figure out a much better THREAD=REFS2?)

Threading is twentysome years old now and nothing much has changed in 
the past 10-15 years. Therefore, I extrapolate to assume that little 
will change in the foreseeable future.

When it comes to the unforeseeable, well, we can deal with that then.

Arnt

---

From: Dan Keen <[email-masked]>
Date: Thu, 5 Aug 2010 09:12:41 -0700

On Aug 5, 2010, at 5:55 AM, Arnt Gulbrandsen wrote:

> Either would be fine with me. I have a preference, but I'd be happy with either.

Devil's advocate here, but this prevents the client from being smarter.

Let's say we have a thread where the client knows some of the messages in the thread are malformed (don't have proper references or in-reply-to), but it doesn't have all the messages in the thread downloaded.

WIthout being able to specify the threading algorithm in the search, we can't say "Hey, on this one, use Subject-based threading because we know it's malformed".

Yes, the client can try to do it's own subject-based threading implementation with multiple searches to the server, but this could be an improvement.

I'd agree it's not necessary, but I want to make sure we know there is a valid use case for it.

D

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Aug 2010 10:10:13 +0200

Dan answers me, I answer Timo: >>> So do you want it to always use 
THREAD=REFS or whatever the server wants
> Devil's advocate here, but this prevents the client from being smarter.

As so often, the best is the enemy of the good.

...
> I'd agree it's not necessary, but I want to make sure we know there is a valid use case for it.

Right.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Aug 2010 09:27:00 +0100

>Devil's advocate here, but this prevents the client from being smarter.
+1.

I don't think Arnt is making very good arguments for removing this 
feature ;-).

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Aug 2010 10:46:17 +0200

> I don't think Arnt is making very good arguments for removing this

Remove, you say? Timo and I are the only implementers so far, and 
neither of us bothered to implement the return option, so I don't think 
"remove" is the right term here.

I stop trying to add a feature because it didn't get traction.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 9 Aug 2010 10:11:53 +0100

On 9.8.2010, at 9.46, Arnt Gulbrandsen wrote:

> Remove, you say? Timo and I are the only implementers so far, and neither of us bothered to implement the return option, so I don't think "remove" is the right term here.

Looks like my current implementation uses the syntax from your earlier drafts:

        search-key   =/ "INTHREAD" SP thread-alg SP search-key

Why was search-alg even moved to a return option?..

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Aug 2010 11:17:44 +0200

> Why was search-alg even moved to a return option?..

Someone (perhaps you, but I'm not sure) suggested that any single search 
command should never be able to use two different threading algorithms.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 09 Aug 2010 13:50:03 +0100

> command should never be able to use two different threading algorithms.

Since I already implemented it, I doubt it was me who suggested changing
it. :) But I remember someone said it would make it more complex to
allow multiple algorithms .. then again, to me the return option seems a
bit ugly/wrong place for it. Return options should control what is
returned from the finished search result, not change what messages
actually match the search query..

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Aug 2010 15:15:09 +0200

On 08/09/2010 02:50 PM, Timo Sirainen wrote:
> it. :)

The name is a digression. Let's not digress (sorry, I started it). Can 
we instead either remove the feature, or else have a use-case good 
enough for use as an example?

> But I remember someone said it would make it more complex to

Yes.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 9 Aug 2010 15:19:37 +0200

> enough for use as an example?

Sorry. Bad wording there.

I'm easily annoyed today. $#@$#@$@ work stuff, nothing to do with morg. 
But if anyone picks nits in my wording today, I'm likely to react very 
badly. Sorry.

Arnt