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

[Alexey Melnikov <[e-mail]>]

Hi Arnt,
Mostly playing devil's advocate below.

Arnt Gulbrandsen wrote:

> On 08/03/2010 06:14 PM, Alexey Melnikov wrote:
>
>> Arnt Gulbrandsen wrote:
>>
>>> Can you suggest some use cases?
>>
>> My understanding is that the parameter changes what is considered to be
>> "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.

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

> 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.

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.

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