Re: Bring back ANNOTATEMORE support
On 09/16/2018 08:29 AM, Bron Gondwana wrote: > Right! OK, we'll add it back in 3.0 and 3.2 then (with a config option > to turn it on), and deprecate it after that :) That's great, thanks Bron. Kind regards, Samir Aguiar
Re: Bring back ANNOTATEMORE support
On Sun, September 16, 2018 07:29, Bron Gondwana wrote: > On Sat, Sep 15, 2018, at 00:20, Samir Aguiar wrote: > >> Hi Bron, >> >> >> On 09/12/2018 03:49 AM, Bron Gondwana wrote: >> >>> Samir: what's your plan for moving those users to something which >>> supports standard ? Because the downside of keeping on supporting a legacy >>> ANNOTATEMORE in Cyrus is that somebody has to >>> maintain that forever if you're never planning to get off it, either you or >>> everyone >>> else touching that code! >> >> Yes, that's a fair point. >> >> >> The plan is to update our client to use METADATA instead of >> ANNOTATEMORE, while keeping support for both in the server. After this >> we deprecate ANNOTATEMORE to signal customers that they should upgrade their >> clients. >> This deprecation should happen mostly likely within two >> years, and in the next years we will be removing it completely from the >> server. > > Right! OK, we'll add it back in 3.0 and 3.2 then (with a config option to > turn it on), > and deprecate it after that :) > > I have CC'd ellie who is making the releases and created > https://github.com/cyrusimap/cyrus-imapd/issues/2525 Thanks. I also need ANNOTATEMORE and METADATA active at the same time. Updating to 3.X would otherwise be impossible. I suspect there are others, perhaps not on this list, with the same needs.
Re: Bring back ANNOTATEMORE support
On Sat, Sep 15, 2018, at 00:20, Samir Aguiar wrote: > Hi Bron, > > On 09/12/2018 03:49 AM, Bron Gondwana wrote: > > Samir: what's your plan for moving those users to something which > > supports standard METADATA? Because the downside of keeping on > > supporting a legacy ANNOTATEMORE in Cyrus is that somebody has to > > maintain that forever if you're never planning to get off it, either you > > or everyone else touching that code! > > Yes, that's a fair point. > > The plan is to update our client to use METADATA instead of > ANNOTATEMORE, while keeping support for both in the server. After this > we deprecate ANNOTATEMORE to signal customers that they should upgrade > their clients. This deprecation should happen mostly likely within two > years, and in the next years we will be removing it completely from the > server. Right! OK, we'll add it back in 3.0 and 3.2 then (with a config option to turn it on), and deprecate it after that :) I have CC'd ellie who is making the releases and created https://github.com/cyrusimap/cyrus-imapd/issues/2525 Cheers, Bron. -- Bron Gondwana br...@fastmail.fm
Re: Bring back ANNOTATEMORE support
Hi Bron, On 09/12/2018 03:49 AM, Bron Gondwana wrote: > Samir: what's your plan for moving those users to something which > supports standard METADATA? Because the downside of keeping on > supporting a legacy ANNOTATEMORE in Cyrus is that somebody has to > maintain that forever if you're never planning to get off it, either you > or everyone else touching that code! Yes, that's a fair point. The plan is to update our client to use METADATA instead of ANNOTATEMORE, while keeping support for both in the server. After this we deprecate ANNOTATEMORE to signal customers that they should upgrade their clients. This deprecation should happen mostly likely within two years, and in the next years we will be removing it completely from the server. Kind regards, Samir Aguiar
Re: Bring back ANNOTATEMORE support
If it's an easy revert, I think we'd be happy to leave it available but marked deprecated with a flag that means you need to explicitly turn it on: deprecated_annotatemore_support: yes And include that in a 3.2 release. Longer term though, the main reason for dropping it is that the annotations code is a weird shape in order to support both old and new style ANNOTATEMORE and METADATA. The plan was to clean up that mess once it no longer had to support METADATA. Samir: what's your plan for moving those users to something which supports standard METADATA? Because the downside of keeping on supporting a legacy ANNOTATEMORE in Cyrus is that somebody has to maintain that forever if you're never planning to get off it, either you or everyone else touching that code! Regards, Bron. On Wed, Sep 12, 2018, at 11:22, Dilyan Palauzov wrote: > Hello Samir, > > if the opt-in ANNOTATEMORE feature is something that only you will use, as it > currently looks like, I see no reason to bother others with it. > > Greetings > Дилян > > On September 11, 2018 2:40:48 PM PDT, Samir Aguiar > wrote: > >Hi Dilyan, > > > >On 09/11/2018 06:17 PM, Dilyan Palauzov wrote: > >> it does not make sense to keep the ANNOTATEMORE code just for your > >specific case. > >> > >> You are entitled to issue an updated client software dealing with > >METADATA and ask users to update, or for your server to revert the > >respective change. > > > >Yes, absolutely. We will need to revert that change and restore > >ANNOTATEMORE support anyway since it's not possible at the moment for > >all of our clients to upgrade. > > > >But I believe my question was ill-phrased. I actually meant to ask if > >such revert, after done by us, would be accepted upstream as an opt-in > >feature, or if the team has already decided to drop that implementation > >for good. > > > >Kind regards, > >Samir Aguiar > -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
Re: Bring back ANNOTATEMORE support
Hello Samir, if the opt-in ANNOTATEMORE feature is something that only you will use, as it currently looks like, I see no reason to bother others with it. Greetings Дилян On September 11, 2018 2:40:48 PM PDT, Samir Aguiar wrote: >Hi Dilyan, > >On 09/11/2018 06:17 PM, Dilyan Palauzov wrote: >> it does not make sense to keep the ANNOTATEMORE code just for your >specific case. >> >> You are entitled to issue an updated client software dealing with >METADATA and ask users to update, or for your server to revert the >respective change. > >Yes, absolutely. We will need to revert that change and restore >ANNOTATEMORE support anyway since it's not possible at the moment for >all of our clients to upgrade. > >But I believe my question was ill-phrased. I actually meant to ask if >such revert, after done by us, would be accepted upstream as an opt-in >feature, or if the team has already decided to drop that implementation >for good. > >Kind regards, >Samir Aguiar
Re: Bring back ANNOTATEMORE support
Hi Dilyan, On 09/11/2018 06:17 PM, Dilyan Palauzov wrote: > it does not make sense to keep the ANNOTATEMORE code just for your specific > case. > > You are entitled to issue an updated client software dealing with METADATA > and ask users to update, or for your server to revert the respective change. Yes, absolutely. We will need to revert that change and restore ANNOTATEMORE support anyway since it's not possible at the moment for all of our clients to upgrade. But I believe my question was ill-phrased. I actually meant to ask if such revert, after done by us, would be accepted upstream as an opt-in feature, or if the team has already decided to drop that implementation for good. Kind regards, Samir Aguiar
Re: Bring back ANNOTATEMORE support
Hello Samir, it does not make sense to keep the ANNOTATEMORE code just for your specific case. You are entitled to issue an updated client software dealing with METADATA and ask users to update, or for your server to revert the respective change. Greetings Дилян On September 11, 2018 5:02:02 AM PDT, Samir Aguiar wrote: >Hi Bron, > >On 09/10/2018 08:26 PM, Bron Gondwana wrote: >> The ANNOTATEMORE was a draft which got replaced with METADATA. If >there >> a reason why you are still using the draft rather than the spec which >> was published in 2009? > >Yes, when our groupware client was planned and developed only >ANNOTATEMORE was available. This client is now is in use at several >thousand customers and we have no control over which software version >they use. > >Samir
Re: Bring back ANNOTATEMORE support
Hi Bron, On 09/10/2018 08:26 PM, Bron Gondwana wrote: > The ANNOTATEMORE was a draft which got replaced with METADATA. If there > a reason why you are still using the draft rather than the spec which > was published in 2009? Yes, when our groupware client was planned and developed only ANNOTATEMORE was available. This client is now is in use at several thousand customers and we have no control over which software version they use. Samir
Re: Bring back ANNOTATEMORE support
Hi Samir, The ANNOTATEMORE was a draft which got replaced with METADATA. If there a reason why you are still using the draft rather than the spec which was published in 2009? Bron. On Tue, Sep 11, 2018, at 09:17, Samir Aguiar wrote: > Hi all, > > We are currently upgrading to 3.0.8, but 3.1.x will probably be stable > by the time we are finished. From what I could see ANNOTATEMORE support > was dropped in 3.1. > > Would it possible to bring it back and maybe make it opt-in in > imapd.conf? Our groupware clients depend heavily on it and it would take > a while until we can fully deprecate it. > > I ran some tests and apparently reverting #26fbf999312 seems to be > enough, but please correct me if I'm wrong. > > Thank you in advance. > > Kind regards, > Samir Aguiar > -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
Bring back ANNOTATEMORE support
Hi all, We are currently upgrading to 3.0.8, but 3.1.x will probably be stable by the time we are finished. From what I could see ANNOTATEMORE support was dropped in 3.1. Would it possible to bring it back and maybe make it opt-in in imapd.conf? Our groupware clients depend heavily on it and it would take a while until we can fully deprecate it. I ran some tests and apparently reverting #26fbf999312 seems to be enough, but please correct me if I'm wrong. Thank you in advance. Kind regards, Samir Aguiar
