A few thoughts

David Ascher

unread,

Oct 18, 2009, 1:27:11 PM10/18/09

to ISP Configuration Database, Philippe M. Chiasson

(reading bug 522253)

I agree, the Thundebird:Autoconfig page needs a rewrite. I suggest we do the following:

- start with a page that describes the exact format used in current version (let's call it 1)
- move everything in that page that doesn't correspond to the current format into a separate page.

Aside: validating against Relax-NG might be easier these days than against a DTD -- and writing a RelaxNG schema is easier than a DTD, and equivalent.

Here's one thing which we probably want to think about very soon, as it may have TB3-blocking implications. We should think a bit about versioning schemas.

1) I don't recall whether Thunderbird exposes a version number in its URL, which live.momo.com could deal with. It should, encoding a version number which is stored in TB (although likely stored as a pref, so that we could work with add-ons to experiment with later versions). In general, we should pass in as much information as we can as parameters to the HTTP request, so that we can deal with things on the server if necessary. As an example, see:

pref("mailnews.migration.header_addons_url","http://live.mozillamessaging.com/%APP%/addons/search?q=header&locale=%LOCALE%&lver=%VERSION%&hver=%VERSION%&os=%OS%");

       let addon_url = Cc["@mozilla.org/toolkit/URLFormatterService;1"]
         .getService(Ci.nsIURLFormatter)
         .formatURLPref("mailnews.migration.header_addons_url");
       document.getElementById("header_addons").setAttribute("href", addon_url);

(in our case, we should add a version=... with a value that's picked out of prefs.)

2) We probably want to include an XML element in the returned data that corresponds to the schema version number, so that when we change the format, various actors can do the right thing. I'm not sure what that is for TB3, though -- maybe refuse to process "future" versioned data?

--david

Louie

unread,

Oct 20, 2009, 12:03:55 AM10/20/09

to ISP Configuration Database

Does this DTD capture all the needed info? I'm not sure what the specs
are because
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
is still a bit confusing.

Please comment so I can get to work on the new export_xml function.

Sample DTD:

<!DOCTYPE root-element SYSTEM "dtd.file">

<!ELEMENT clientConfig (emailProvider)>

<!ELEMENT emailProvider (domain, displayName,displayShortName,
incomingServer, outgoingServer)>
<!ATTLIST emailProvider id CDATA "example.com" >

<!ELEMENT domain (#PCDATA)>
<!ELEMENT displayName (#PCDATA)>
<!ELEMENT displayShortName (#PCDATA)>

<!ELEMENT incomingServer (hostname, port, socketType, username,
authentication)>
<!ATTLIST incomingServer type CDATA "pop3">
<!ELEMENT hostname (#PCDATA)>
<!ELEMENT port (#PCDATA)>
<!ELEMENT socketType (#PCDATA)>
<!ELEMENT username (#PCDATA)>
<!ELEMENT authentication (#PCDATA)>

<!ELEMENT outgoingServer (hostname port, socketType, username,
authentication, addThisServer, useGlobalPreferredServer)>
<!ATTLIST outgoingServer type CDATA "pop3">
<!ELEMENT hostname (#PCDATA)>
<!ELEMENT port (#PCDATA)>
<!ELEMENT socketType (#PCDATA)>
<!ELEMENT username (#PCDATA)>
<!ELEMENT authentication (#PCDATA)>
<!ELEMENT addThisServer (#PCDATA)>
<!ELEMENT useGlobalPreferredServer (#PCDATA)>

On Oct 18, 10:27 am, David Ascher <dasc...@mozillamessaging.com>
wrote:

> (reading bug 522253)
>
> I agree, the Thundebird:Autoconfig page needs a rewrite. I suggest we do
> the following:
>
> - start with a page that describes the exact format used in current
> version (let's call it 1)
> - move everything in that page that doesn't correspond to the current
> format into a separate page.
>
> Aside: validating against Relax-NG might be easier these days than
> against a DTD -- and writing a RelaxNG schema is easier than a DTD, and
> equivalent.
>
> Here's one thing which we probably want to think about very soon, as it
> may have TB3-blocking implications. We should think a bit about
> versioning schemas.
>
> 1) I don't recall whether Thunderbird exposes a version number in its
> URL, which live.momo.com could deal with. It should, encoding a version
> number which is stored in TB (although likely stored as a pref, so that
> we could work with add-ons to experiment with later versions). In
> general, we should pass in as much information as we can as parameters
> to the HTTP request, so that we can deal with things on the server if
> necessary. As an example, see:
>

David Ascher

unread,

Oct 20, 2009, 12:20:42 AM10/20/09

to Louie, ISP Configuration Database

Ugh, this is one reason why I don't like DTDs. There's almost no
structure in this DTD, meaning it won't actually give you good test
coverage. It might be valid, but it's not that helpful.

See http://www.relaxng.org/tutorial-20011203.html for a quick tutorial
for Relax-NG, and
http://stackoverflow.com/questions/1254919/how-do-i-validate-xml-document-via-relax-ng-schema-in-python
for a quick sample of how to validate an XML doc using a RelaxNG schema.

Reply all

Reply to author

Forward