First, sorry for taking this long to respond. Just been so tired all week. Anyway, most of what is said below looks sane to me. Just a few comments/questions below.
On Tuesday 20 February 2007 05:45, Jon Keating wrote: > Owner:: The local user that uses a protocol plugin, which generally > requires a username and password. I'm assuming that only username is required? Not everybody likes to store their password on disk, so it should be possible to have an owner without a password. The plugin can then send a broadcast message (or event as it is called elsewhere) to all plugins requesting a password for account X. The user can then enter it and send it back to the plugin. > An exisiting account will be entered into the daemon via the ui plugin > and saved via an API call (CUserManager::addUser()). I've been thinking about how plugins should communicate with each other, and without getting into the details too much (TODO: write a document about it) the idea is simply that plugins send messages to each other (inspired by the events discussion on the wiki, but messages is IMHO a better name). So this is how I imagine the above being done with messages. [For those interested, this is how I'm thinking that the data structure for a message should look like. And yes, it is still called event, even if I prefer message. http://trac.licq.org/browser/branches/erijo-dev/licq/licq/interface/event.h] 1. User selects "add existing user account" in the gui. 2. The gui queries the daemon for a list of all protocols supported and presents the user with a dialog where he/she can enter username, password and select protocol from a combo box. 3. The gui asks the daemon to create a new instance of the protocol plugin that the user has chosen. The id of the newly created plugin is returned. 4. The gui creates a message "add-existing-account" and sets the properties username and password (and perhaps a boolean for save-password) and sends it to the plugin. 5. The plugin connects to the server, validates credentials, fetches owner information and creates a TOwner (= an username and any number of key/value pairs, similar to IEvent). Ownership of the owner instance is transfered to the daemon that is responsible for saving and loading owners. 6. The plugin broadcasts a message to all plugins informing them that a new account has been added. > Creating a new account can only be done if the protocol plugin > supports the feature. (TODO: A method of querying what a protocol plugin > supports will need to be added) Perhaps a message "get-capabilities"? > When an account is made, the protocol plugin will automatically > make the newly created account be the owner for the given protocol > plugin instance. In my mind, this is similar to add account above, but with the message "create-new-account". All the mentioned stages would be done by sending a few messages (e.g. "captcha-image") between the protocol and gui. > === Loading Owners === > The ui plugin will make a call to IPlugin::setOwner(TOwnerId) to > specify the owner for the protocol plugin instance. Once an owner is set, it > cannot be changed. A new plugin instance will need to be created. I don't think the ui should do this. This should be done by the daemon on load. I think the the daemon should create a TOwner instance, load it with settings from disk and tell the plugin to use that instance. // Erik -- Don't worry, tomorrow won't be a better day! Erik Johansson http://ejohansson.se
pgpNEuWqvQcQM.pgp
Description: PGP signature
