Bug 634078 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification anyways, but with a different UI, which causes additional complexity in the code. The user might think that it's the same to enter the password here or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP. I think that leads to a bad UX.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different UI, which causes additional complexity in the code. The user might think that it's the same to enter the password here or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP. I think that leads to a bad UX.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password here or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP. I think that leads to a bad UX.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password in the beginning or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP. I think that leads to a bad UX.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password in the beginning or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password in the beginning or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, and might have strong opinions on this, so I will yield to the powers that be.
I personally think that we should enforce a password before we start the setup process. It makes very little sense to enter the password every time we log in, particularly given that we open new IMAP connections *per folder* on an as-needed basis during daily use, so storing the password (on the local computer) is the only practical way. The edge case user who absolutely doesn't want to do that can still remove the password later, and or enter a wrong password.

Not requiring the password means that some setup machanisms will fail later on, without the user being aware of it. We will require the password later on during account verification/validation anyways, but with a different password UI, which causes additional complexity in the code. The user might think that it's the same to enter the password in the beginning or at a later step, but it's not, because he'll have to enter the password 3 times: For the account verification, then immediately after setup *again*, to get the emails in the inbox, and then *again* when he sends an email, because we were not able to store the password for SMTP.

This also complicates the code, because on every step, we always have to consider the case that we need to login, but the user hasn't given us the password, so we have to consider whether we proceed without login, or whether we ask for the password again (with different UI). If we can assume that the user entered the password, it simplifies the code. That, in combination with the first point that a realistic use without storing the password is hard, I would not support this option.

That said, I understand that other people hold differing opinions from mine, so I will yield to the powers that be.

Back to Bug 634078 Comment 9