556140 - Create live.mozillamessaging.com/autoconfig/v1.1/

Status: RESOLVED FIXED

(Webtools :: ISPDB Server, defect)

Description

[Ben Bucksch (:BenB)]

Bug 531267 changed the config file reading to allow new format features like a second <incomingServer>. We need this for bug 532590 to add a POP server in addition to the IMAP server (and allow the user to choose). However, such a second <incomingServer> would break TB 3.0 (that's exactly what the bug fixed), so we need a different server URL and fork the files.

Step 1:
- mkdir autoconfig/v31/
- cp -a autoconfig/*.* autoconfig/v31/
Step 2:
- Change TB client (3.1 only) to hit the new URL.
  One-liner, we could do this in this bug.
Step 3:
- Change configs to add POP server and generally to new format.
  This will be handled in a separate bug.

The URL is up for debate. Alternatives e.g.
- autoconfig/v3.1/
- autoconfig/v1.1/
- autoconfig-v31/
- autoconfig-v1.1/

Comment 1

[Blake Winton (:bwinton) (:☕️)]

For reference, and as a vote, /v3.1/ is what the ISPDB uses, but I think /v1.1/ would be a better choice, to divorce it from Thunderbird's version number.

Thanks,
Blake.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> For reference, and as a vote, /v3.1/ is what the ISPDB uses, but I think /v1.1/
> would be a better choice, to divorce it from Thunderbird's version number.

I agree with the 1.1 - otherwise we'd be implying we have to update the version number for each version of Thunderbird that we release, whether we make changes or not.

Comment 3

[Ben Bucksch (:BenB)]

OK

Comment 4

[Philippe M. Chiasson (:gozer)]

(In reply to comment #0)
> Bug 531267 changed the config file reading to allow new format features like a
> second <incomingServer>. We need this for bug 532590 to add a POP server in
> addition to the IMAP server (and allow the user to choose). However, such a
> second <incomingServer> would break TB 3.0 (that's exactly what the bug fixed),
> so we need a different server URL and fork the files.

What's the plan for continuing to provide updates for the files in the 3.0 format?

My suggestion would be a tool/script that can produce 3.0 safe files from the new format ones. That way, we just switch over to the new format, and let that tool take care of down-converting these new files into something TB 3.0 can digest.

Comment 5

[Ben Bucksch (:BenB)]

> What's the plan for continuing to provide updates for the files in the 3.0
> format?

As shortly discussed on tb-planning:
- First, we just copy
- Then, we sync manually as needed
- Or we write a converter, as you and bwinton suggested.

> My suggestion would be a tool/script that can produce 3.0 safe files from the
> new format ones.

That'd be my preference. Maybe we can use some code from ISPDB, or maybe it's simple to write a simple tool from scratch. Should be easy enough (2h?). I probably won't do it myself, though.

Comment 6

[Blake Winton (:bwinton) (:☕️)]

My plan was that we convert the files manually until it gets too annoying, then someone pokes me in the head until I write a converter.  ;)

Later,
Blake.

Comment 7

[Philippe M. Chiasson (:gozer)]

live.mozillamessaging.com/autoconfig/v1.1/ is now visible and was just a svn copy.

Comment 8

[Ben Bucksch (:BenB)]

Cool, thanks!

Comment 9

[Ben Bucksch (:BenB)]

Attachment: Change URL in client

Step 2

Comment 10

[Ben Bucksch (:BenB)]

Attachment: Change URLs in client

This also changes the URL for fetch from ISPs to 1.1, per bwinton.

Comment 11

[Ben Bucksch (:BenB)]

Filed bug 556729 about improving the v1.1 config files.

Comment 12

[Ben Bucksch (:BenB)]

Filed bug 557401 about the converter from v1.1 to v1.0.

Comment 13

[Ben Bucksch (:BenB)]

Comment on attachment 436592 [details] [diff] [review]
Change URLs in client

bwinton: trivial patch, please review

Comment 14

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 436592 [details] [diff] [review]
Change URLs in client

Looks good to me.

Comment 15

[Ben Bucksch (:BenB)]

Commited as <http://hg.mozilla.org/comm-central/rev/83e6b3354052>

FIXED