1364715 - Flaws in 'prefs.js' architecture - potential bugs

Status: RESOLVED INVALID

(MailNews Core :: Account Manager, defect)

Description

[u328884]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.9) Gecko/20100101 Goanna/3.0 Firefox/45.9 PaleMoon/27.0.3
Build ID: 20161214135803

Steps to reproduce:

(Architecture comment, not bug.)


Actual results:

(Architecture comment, not bug.)


Expected results:

Here are TYPICAL lines are from scattered sections of my TBird's 'prefs.js' file:

    user_pref("mail.identity.id19.smtpServer", "smtp30")
    user_pref("mail.identity.id19.useremail", "[e-mail]")
    user_pref("mail.server.server22.name", "wikipedia")
    user_pref("mail.server.server22.userName", "[e-mail]")


Account Property Chain.

The 'user-pref' functions above form a property chain.
The property chain defines how TBird links an account name ("wikipedia"), its account identifier (id19), its POP server (server22) & its SMTP server (smtp30).
Here is the property chain:

    "wikipedia" -- server22 -- "[e-mail]" -- id19 -- smtp30.

Constructing the property chain logically starts with an account name (for example, "wikipedia") as it is shown in the folder pane (left-hand panel) in TBird.

    user_pref("mail.server.server22.name", "wikipedia")

So server22 is the incoming server for the "wikipedia" account. Schematically, let's show that relationship like this:

    "wikipedia" -- server22.

Nearby (in 'prefs.js') is the userName for the account that uses server22:

    user_pref("mail.server.server22.userName", "[e-mail]")

So server22's userName is "[e-mail]". Schematically, let's show that relationship like this:

    server22 -- "[e-mail]".

Next, searching on that userName ("[e-mail]") discloses its identity:

    user_pref("mail.identity.id19.useremail", "[e-mail]")

So "[e-mail]" is id19. Schematically, let's show that relationship like this:

    "[e-mail]" -- id19.

Finally, searching on that id (id19, without quotes) discloses its SMTP server:

    user_pref("mail.identity.id19.smtpServer", "smtp30")

So id19's smtpServer is smtp30. Schematically, let's show that relationship like this:

    id19 -- smtp30.

Thus, my "wikipedia" account's property chain is:

    "wikipedia" -- server22
                   server22 -- "[e-mail]"
                               "[e-mail]" -- id19
                                                      id19 -- smtp30
or
    "wikipedia" -- server22 -- "[e-mail]" -- id19 -- smtp30.


I've left arrows out of the property chain because I can't formulate a consistent answer to this question:
Should the arrows point according to assignment: obj.prop <-- val, or according to ownership: obj --> prop?
Either way, analyzing the property chain can be crazy-making.
Better to not show any arrows and to stick with simple relationships: obj -- prop.


Crosslinks.

There are crosslinks in 'prefs.js'.

    user_pref("mail.account.account119.identities", "id19")
    user_pref("mail.account.account119.server", "server22")
    user_pref("mail.smtpserver.smtp30.username", "[e-mail]")

They create, respectively:

    account119 -- id19
    account119 -- server22
    smtp30 -- "[e-mail]"

Adding the crosslinks to the existing account property chain produces this picture:

                                                                +-----------+
                                                                |           |
    "wikipedia" -- server22 -- "[e-mail]" -- id19 -- smtp30    account119
                      |                 |                       |           |
                      |                 +-----------------------+           |
                      +-----------------------------------------------------+

Contained therein are 3 loops:

                                                        +-------------------+
                                                        |                   |
                   server22 -- "[e-mail]" -- id19              account119
                      |                                                     |
                      |                                                     |
                      +-----------------------------------------------------+

                                                        +-------------------+
                                                        |                   |
                   server22 -- "[e-mail]"    id19 -- smtp30    account119
                      |                 |                       |           |
                      |                 +-----------------------+           |
                      +-----------------------------------------------------+


                               "[e-mail]" -- id19 -- smtp30
                                        |                       |
                                        +-----------------------+

'prefs.js' is essentially a sparse relational database.
It can be traversed by ownership: obj <-- prop, or by search: prop --> obj.
The loops represent potential design flaws that, depending on the direction of traversal, can manifest as static or dynamic bugs.


I also suggest that a 3rd argument be added to each user_pref in 'prefs.js'.
The 3rd argument would record the date & time that the property value (the 2nd argument) was last altered.
The 3rd argument would be helpful when troubleshooting 'prefs.js'.

Comment 1

[:aceman]

I don't think there are any loops in the prefs. All the account properties should form should be a tree (acyclic graph).

You made some errors in your assumptions:

(In reply to Mark Filipak from comment #0)
> Constructing the property chain logically starts with an account name (for
> example, "wikipedia") as it is shown in the folder pane (left-hand panel) in
> TBird.
> 
>     user_pref("mail.server.server22.name", "wikipedia")

No, you can start from the account prefs:
user_pref("mail.account.account1.identities", "id1");
user_pref("mail.account.account1.server", "server2");

So this account1 connects server2 (incoming server) and id1 (identity).
There must only be exactly 1 server for an account, but there can be more than 1 identities.

So you look up the properties of the identity"
user_pref("mail.identity.id1.*", ...)

And you look up properties of the server:
user_pref("mail.server.server1.*", ...)
One of the properties is the name which is used as the account name.

One of the properties of each identity is the smtpserver ID:
user_pref("mail.identity.id1.smtpServer", "smtp1");

So you lookup its properties:
user_pref("mail.smtpserver.smtp1.*", ...);

> Next, searching on that userName ("[e-mail]") discloses its
> identity:
> 
>     user_pref("mail.identity.id19.useremail", "[e-mail]")

Incorrect. You can't find the identity by the username. The identity contains your email, not the username to your incoming server. Those do differ. They only sometimes are the same, as in your case.
So you can't make this connection.

 
> Thus, my "wikipedia" account's property chain is:
> 
>     "wikipedia" -- server22
>                    server22 -- "[e-mail]"
>                                "[e-mail]" -- id19
>                                                       id19 -- smtp30
> or
>     "wikipedia" -- server22 -- "[e-mail]" -- id19 -- smtp30.

No, the links are:
account1
  +---> server1
  +---> id1
         +--> smtp1

> I've left arrows out of the property chain because I can't formulate a
> consistent answer to this question:
> Should the arrows point according to assignment: obj.prop <-- val, or
> according to ownership: obj --> prop?

I have written how the arrows operate. You can't got backwards, i.e. having an identity in your hand, you can't go directly to the account via some link or pointer. You have to loop over all accounts to see which one references it.

>                                                                 +-----------+
>                                                                 |           |
>     "wikipedia" -- server22 -- "[e-mail]" -- id19 -- smtp30   
> account119
>                       |                 |                       |           |
>                       |                 +-----------------------+           |
>                       +-----------------------------------------------------+

Incorrect graph.
 
> Contained therein are 3 loops:
> 
>                                                         +-------------------+
>                                                         |                   |
>                    server22 -- "[e-mail]" -- id19             
> account119
>                       |                                                     |
>                       |                                                     |
>                       +-----------------------------------------------------+

Incorrect graph. There is no link between id19 and server22. You just made it up.
 
>                                                         +-------------------+
>                                                         |                   |
>                    server22 -- "[e-mail]"    id19 -- smtp30   
> account119
>                       |                 |                       |           |
>                       |                 +-----------------------+           |
>                       +-----------------------------------------------------+
> 

Incorrect graph. There is no link between smtp30 and your 
"[e-mail]" server. It is again just a username for your smtp server, does not necessarily have to be the same as your username on incoming server (pop3 or imap4) OR your email address as displayed in messages.
 
>                                "[e-mail]" -- id19 -- smtp30
>                                         |                       |
>                                         +-----------------------+

Incorrect.
 
> 'prefs.js' is essentially a sparse relational database.
> It can be traversed by ownership: obj <-- prop, or by search: prop --> obj.

No, it can't, there are no direct links backwards.

> The loops represent potential design flaws that, depending on the direction
> of traversal, can manifest as static or dynamic bugs.

I see no loops.
 
> I also suggest that a 3rd argument be added to each user_pref in 'prefs.js'.
> The 3rd argument would record the date & time that the property value (the
> 2nd argument) was last altered.
> The 3rd argument would be helpful when troubleshooting 'prefs.js'.

There should be no loops.

Only if e.g. multiple accounts reference the same server or the same identity, there is a problem and a bug in TB. But there still won't be a loop.

Comment 2

[Alfred Peters [:infofrommozilla]]

(In reply to :aceman from comment #1)

You were a tick faster than me. :-)
Therefore only a few additions.

> One of the properties of each identity is the smtpserver ID:
> user_pref("mail.identity.id1.smtpServer", "smtp1");

mail.identity.id<o>.smtpServer  is an optional specification.
If it is not set, mail.smtp.defaultserver is used instead.

> > The loops represent potential design flaws that, depending on the direction
> > of traversal, can manifest as static or dynamic bugs.
> 
> I see no loops.

Agreed. There are none.

For further information:
http://kb.mozillazine.org/Mail_and_news_settings
http://kb.mozillazine.org/Multiple_identities_per_e-mail_account
http://kb.mozillazine.org/Multiple_SMTP_servers_-_Thunderbird

Comment 3

[Wayne Mery (:wsmwk)]

I enterpret comment 1 and comment 2 as being, this is not a bug