MBOX-Line: From snowjn at aol.com  Fri Jun 11 16:52:23 2010
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] IMAP MOVE extension
In-Reply-To: <alpine.BSO.2.00.1006111628220.28689@vanye.sendmail.com>
References: <201006110854.37969.witold.krecicki@firma.o2.pl>	<201006112352.05642.witold.krecicki@firma.o2.pl>	<alpine.BSO.2.00.1006111511070.10697@vanye.sendmail.com>	<201006120124.53714.witold.krecicki@firma.o2.pl>
	<alpine.BSO.2.00.1006111628220.28689@vanye.sendmail.com>
Message-ID: <4C12CC37.2090200@aol.com>



Philip Guenther wrote:
> On Sat, 12 Jun 2010, Witold Kr?cicki wrote:
>   
>> On Saturday 12 of June 2010 01:16:36 Philip Guenther wrote:
>>     
> ...
>   
>>> Uh, what?  It sounds like you're saying that you're going to build a 
>>> system where MOVE is fast (so single message rename is fast) but then 
>>> intentionally *not* take advantage of the design to use hardlinks to 
>>> make COPY fast.  Claiming that using hardlinks is "not a normal 
>>> method" when it's been in use for better than a decade requires some 
>>> justification.
>>>       
>> Even if used for over a decade it is STILL a performance hack.
>>     
>
> And hash tables have been a performance hack for 5 decades.
>
> Or do you have an *OBJECTIVE* criteria for what makes something a 
> performance hack that the rest of us can use to understand why you refuse 
> to use a supported feature of the data structures that we call a 
> filesystem?
>
>
>   
>>>>> IMAP has generally not added features whose sole purpose is to 
>>>>> provide support for a particular type of store.  Far more common 
>>>>> is that a particular type of store has vetoed a proposed addition.
>>>>>           
>>>> MOVE creates advantage for any kind of single-labeled flat store.
>>>>         
>>> So you agree with Mark that it's only for a particular type of store 
>>> that this helps.
>>>       
>> No, I'm showing that there is a store in which this helps. There may be 
>> other types.
>>     
>
> That still sounds like you agree, even though you don't want to.  "There 
> may be others" could be said about *anything*.  If there's an example 
> that's significantly different than the "single-labelel flat store" for 
> which MOVE is an advantage, cite it.
>
>
>   
>>>> Most of the people here (I'm silently assuming that they are not all 
>>>> newcomers) agreed that it is in fact a needed feature.
>>>>         
> ...
>   
>> No, I'm simply assuming that those who are not willing to take part in this 
>> discussion do not have an opinion.
>>     
>
> I'll just quote those two sentences of yours and say that they are in 
> conflict.
>
>
>   
>> Daves argument that the idea of 'trash can' is broken and people should 
>> just delete their mails (or IMAP should create a 'trash can' model) it's 
>> IMHO simply out of this world - people want to have a trash can and be 
>> able to recover deleted e-mails.
>>     
>
> It's been discussed multiple times in the past (oh, why does no one 
> actually read the archives?) how to implement the Trash Can UI on top of 
> the IMAP \deleted+EXPUNGE model.  And guess what, that can do something 
> the "trash can is a mailbox" model can't: undelete restores the message to 
> its original place in the mailbox.
>
>   
I agree this is a great feature, but I haven't met a user who cares.  
Thanks to the Mac,
Windows and Linux GUI's, users are used to the trash can model of 
deleting things.
I think a user explicitly moving something from trash to wherever they 
want is far
easier to understand than trying to remember where it was originally 
deleted from.
But, of course, that's just my opinion.

snow.
> Philip Guenther
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20100611/1f738c8e/attachment.html>
