I just added the Owner document to the Wiki, you can see it at the
following URL: http://trac.licq.org/wiki/DeveloperArea/PluginApi/Owner

I'll insert to the document here (with Wiki Formatting) to discuss it.
It still isn't complete, but most of the ideas are here. I don't go
into the details of owner information, as that will be tied to the
user document, so I'd like to have it specified there.

Jon

----------------------

= Owner =

 Owner:: The local user that uses a protocol plugin, which generally
requires a
 username and password.

== Plugin Usage ==

An interface plugin will be responsible for the handling of owners.
The protocol
plugin instance will only handle an owner that it is designated as
being
responsible for by the interface plugin. Each protocol plugin instance
will be
allowed to support one owner, but there may be multiple protocol
plugin
instance's of any given protocol plugin.

== Flow ==

The first time a protocol plugin instance is created, it will not have
an owner
so any activities that require an owner (i.e. login) will result in an
error
until an owner is assigned to the instance.

== Protocol Plugin Startup ==

Ideally, when a protocol plugin is started, an owner should be
assigned to it
shorty after the plugin is loaded. Otherwise, it can't be used and
there really
is no reason to load the plugin. In the event that an owner for the
protocol
plugin does not exist, an owner will need to be created. There are 2
different
types of owner creation:

 * Add existing account
 * Create new account

=== Existing Accounts ===

An exisiting account will be entered into the daemon via the ui plugin
and saved
via an API call (CUserManager::addUser()).

=== Creating New Accounts ===

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) When an account is made, the protocol plugin will
automatically
make the newly created account be the owner for the given protocol
plugin
instance.  Additionally, some some protocols require more than a
username and
password to create an account. For example, ICQ and Yahoo! have a
captcha image
in the final stage. The ui plugins will have to be flexible enough to
work with
this, so the process will be defined by stages that it must progress
through.
The protocol plugin will skip any stages that it will not perform.

 * Stage 1: Get Input Fields. The ui plugin asks the protocol plugin
for the
   fields to prompt the user for.

 * Stage 2: Send Data to Server. The ui plugin pushes the data to the
protocol
   plugin and then waits for the next action to perform.

 * Stage 3: Captcha. The protocol plugin tells the ui to get a
response for the
   captcha image.

 * Stage 4: Done. The user has been successfully registered. Notify
all plugins.

At any point, the protocol plugin can return an error that requires
the input to
be redone. More details on this will need to be decided in the future.
The
protocol plugin will set the stage it is at, so more stages can be
added to the
API without affecting current protocol plugins, and allow the UI
plugins to
reflect the changes.

=== 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.

== Owner Management ==

The daemon will be responsible for saving the owner details to disk
and loading
them on Licq startup. The daemon will be able to allow plugins to see
all owners
that are currently loaded and allow iteration through the list.

=== File Format ===

The owners will be saved in an XML format. This will allow a cleaner
and easier
to handle format for loading and saving the information. The reason to
not use
the current CFile is due to it having some minor flaws.

-------------

Reply via email to