On Monday 12 August 2013 18:22:59 Jan Kundrát wrote: > On Sunday, 11 August 2013 11:57:59 CEST, Pali Rohár wrote: > > Both plugins passes information in signals params. This is > > unified. But only in ComposeWidget.cpp code I need sender() > > because pointer of Job is removed from queue. This is needed > > because ComposeWidget had sync API for completion and it was > > not easy to rewrite code to use new async addressbook job > > without sender(). > > Now I took a second look. I was under impression that you > followed Kevin's advice about always including the Job *job > parameter in the jobs' signals. However, looking at the > actual code now > (pali/pali-gsoc:src/Plugins/AddressbookPlugin.h, > pali/pali-gsoc:src/Plugins/PasswordPlugin.h), it looks like > these parameters were removed. Is that right? If yes, why did > you remove them? Apologies if I'm missing something obvious. >
Yes, I removed them because at that time parameter was never used. Later when I rewritten ComposeWidget code I needed it (only) there. > > And then I remove description from trojita settings. > > Thanks for this. > > > I do not like this automagic idea of selecting plugins. I > > bet that in some specific situation & configuration it will > > not work as user expect... > > That's a very good point -- shipping a code which is as robust > as possible makes a lot of sense, and limitting needless > options is a way to increase this robustness. However, in > this situation, I'm worried about whether the plugins will > get any usage when they are disabled by default. > > What do you propose? > > > I only need unique qstring identifier for each account. And > > this string needs to be passed to each PasswordJob > > operation. > > > > So until multiple account support is there, I can use unique > > string "1" (now it is username). And then when multiple > > accounts will be there you will pass account identifier > > instead "1". Ok? > > Ah, I was under impression that the password backends actually > could make use of some better-structured data, like "this is > a password for *John* for his *IMAP* account at > *example.org*". If this is wrong, i.e. if the backends don't > care about this data then, an "account ID" is enough. > I do not want to tell password plugin that "this is password for username ABC for server XYZ", because both ABC and XYZ can be changed, but password not. Imagine that ip address (or dns name) of server will be changed and then user lost his password... Or due to server migration user's login name will be changed (but he will have same email address and same messages on imap server which changed dns name). So unique account ID which will never change solving these problems. And password storage do not need to know that this password belongs to imap user on server... -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
