[MlMt] Lost tags?

[Robert Brenstein]

On 18 Jan 2019, at 16:02, Benny Kjær Nielsen wrote:

> On 16 Jan 2019, at 15:05, Robert Brenstein wrote:
>
>> On 16 Jan 2019, at 10:12, Benny Kjær Nielsen wrote:
>>
>>> On 11 Jan 2019, at 17:25, Eric Sharakan wrote:
>>>
>>>> In cases where MM can detect servers that don't support persisting 
>>>> IMAP keywords, it would sure be useful if that could be indicated 
>>>> to the user in some form.  I know for a fact our corporate IMAP 
>>>> server doesn't support them, but for my other accounts I'm not 
>>>> sure.
>>>
>>> Agreed.
>>>
>>> It's not obvious how/when to best do this, but I'll give it some 
>>> thought (which I haven't really ever done). For example, the user 
>>> might have added a tag to a message in one account and then later 
>>> moved it to an account without support for IMAP keywords. Also, 
>>> servers always support, e.g., `\Flagged` which means that any tag 
>>> bound to this does work even when other tags do not.
>>>
>> I would check whether a given server supports tags when a new IMAP 
>> source is being added and keep that as a setting/property for that 
>> account within MM, displaying user a warning when the account is 
>> added. I’d also add a user setting whether to display further 
>> warnings or not.
>
> That's the simple solution, but as I tried to argue then it's not as 
> simple as that. Mailboxes within the same account can have different 
> policies. Servers/mailboxes may support different sets of IMAP 
> keywords. Messages might be moved from one account to another. I 
> really think it's best to somehow make each tag stand out for a single 
> message when there is a synchronization-limitation. And then somehow 
> make it easy for the user to see why it stands out.
>
> (Anything is really better than the current silent handling/failure.)

Yes, I agree. What I meant is that users get a warning right away when 
connecting a source, so they are aware from the beginning whether tags 
for this source are local only or not. Since MM then knows whether a 
given service supports tags or not, it can warn and act accordingly for 
all those operational cases that you list (if user wishes to see further 
warnings). I would not mind if you made it binary, at least to begin 
with, that is identifying each service for each source account as 
supporting tags fully or not, partial support not being considered 
unless workabout is easy and useful. For example, my having CommuniGate 
Pro Server which supports only 4 custom flags is as good as having no 
support for tags.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freron.com/pipermail/mailmate/attachments/20190118/dbf5666c/attachment.html>