These are my suggestion on the owner handling and also the handling of
protocol plugins.
It is more of an alternate idea than comments to Jon but this is how I
think it should work.
/Anders
If think it would be more practical to separate protocol handling from the
plugin handling.
This would mean that all plugins are loaded and handled the same way
regardless if its a protocol, user interface or other type of plugin. This
will make plugin handling easier in both the daemon and in the gui.
I haven't looked into the code of any other IM-client but the GUIs of
several I've seen gives me the impression that this is how it works.
A plugin containing a protocol would on initialization register a factory
with the protocol manager in the daemon. (It could even support multiple
protocols and call the register function multiple times to register all
the protocols. Or it could include both a protocol implementation and a UI
specific to that protocol.)
Each configured owner will on load (or creation) be handled by an instance
of a protocol implementation created by calling the factory registered for
that protocol.
I think owners should be managed in the daemon but it will only need the
protocol name and owner id form the owner configuration. The rest
(xml-block holding any amount of parameters) is passed on to the protocol
implementation instance on creation.
From here the daemon could more or less handle the owners with a map with
owner id as key and the protocol instance as value so the owner manager
should not have be very advanced.
The daemon will handle multiple owners of the same protocol in the same
way as if they used different protocols. The daemon (and other plugins)
talk with the instances, not the plugins they belong to.
Each instances run separatly and should not need to share event handling,
threads or any other resource unless it is in some way required by the
actual protocol.
A protocol that is not used (i.e. no owner is configured that uses it)
will do nothing and will not use any resources (the factory is never
called to create any instance of the protocol code). UI plugins will
normally start a thread and listen to events but the plugin part of the
protocol plugin will not need any of that. When (and if) plugin instances
are created they will start what ever theads, event handling, sockets etc
they need.
Having multiple owners using the same protocol would only require that the
plugin does not uses global or static data and that it is thread safe.
There should be no difference in how the first owner of a protocol is
created and how additional owners are added. (Only exception to this would
be if licq on startup has no owners at all, but guiding the user to adding
the first user should be a part of the UI, not the daemon.)
Registering a new user might require special handling.
One way is to register a second factory on init (together with the normal
factory) that can provide registration of a new user. The registration
object has another API that includes calls for the different stages of
registration (as described by Jon). After registration is completed it
could return either a started plugin instance or a configuration block
(xml) that can be used to create an instance via the normal factory.
Another way would be to create an instance as normal but with empty
configuration (or a flag set) and then the normal API would have to
include the neccecary methods for registering a user. When registration is
complete it will behave as a normal protocol instance.
I like the first approach best as registering a user will require special
steps (as described by Jon) that may be very different to how the protocol
operates in normal cases.
It should also be possible to have a protocol implementation that cannot
register new users for some reason.
