On Wed, 21 Feb 2007 05:40:41 +0100, Jon Keating <[EMAIL PROTECTED]>
wrote:
On Feb 21, 3:13 am, "Anders Olofsson" <[EMAIL PROTECTED]> wrote:
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
Isn't this basically what Erik was talking about in his document about
plugins? He has a factory that is created in the plugins to register
what type of plugin they are and other information. It will probably
be needed to have more factories to have more information...
As I have understood it, protocol plugins would be treated differently
from other plugins (use another API) at the plugin level. What I would
like is to have all plugins handled the same way and move the protocol
handling away from the plugin API.
There shouldn't be different types of plugins when looking at the plugin
API. This will allow one plugin to contain multiple types of functions and
I think it would be messy in both the daemon and UIs to have different
types of plugin APIs.
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.
So the protocol plugin will load the owners in the initialization? How
would it know which owner to create? If you have Owner1 and Owner2 of
Protocol1, how does the initilization of Protocol1 know which owner to
load?
Owner id and configuration for the owner is passed to the protocol
instance from the daemon upon creation. The daemon will know which owners
are configured and load them. Creating protocol instances will be part of
that loading.
Each instance of a protocol handles one owner only. (Of course the plugin
may may share data internaly but the daemon will always handle them as two
different instances.)
I was thinking that the UI plugin will display an Owner Manager to
startup the instances and tie them with the proper owner. So... as you
say....
I'm talking mostly about normal startup of a fully configured licq. Not
the first run and setup.
What you have written above sounds to me that the UI will be invoked on
startup to start all owners. I'm assuming you mean it should just be used
to create the owners the first time not every time licq is started.
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.
The daemon will manage the owners, mainly in the form of passing the
data around and assigning owners to protocol plugin instances. As for
the XML block passing around... not quite sure what you mean by that,
just assigning by TOwnerId will allow the plugin to access the data
from the class. Perhaps in a generic way, like the way we pass events
around EventData::addData("messageText", "This is a test message").
Each protocol will have different types of data to describe the owner
(and users), so we should be as flexible as possible to make it work
without any overly complex parts. (the current ICQOwner has *lots* of
data fields attached to it... which doesn't do anything but waste
memory for MSN owners).
"xml-block" refers to the configuration data for the owner that is used by
the protocol plugin. You mentioned using xml for config files which I
think could be a good solution for flexability (compared to a flat
ini-file) I therefore wrote "xml-block" to refer to that data in whatever
form it will be runtime.
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.
What is needed is the plugin information, otherwise it will be hard to
load the plugins from a GUI. That is part of Erik's document, and it
looks like that portion will be loaded into memory for all plugins.
Erik, is that correct?
Of course a loaded plugin will always result in the daemon holding some
information about it. What I mean here is that there will be no threads,
event handlers, sockets, etc active in an unused protocol plugin, only the
bare minimum required to actually have the plugin loaded.
You described an unused protocol plugin as an error-case which I think it
does not has to be. Just by registering one (or more) protocols it will
give the user additional protocol(s) to choose from in the UI protocol
manager. The user should not be forced to immediatly create a user when
the plugin is loaded the first time. (However, when the new protocol is
registered this my generate an event allowing the UI to ask the user if
he/she would like to create a new owner, but that should be up to the UI,
not forced by the daemon.)
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
Well, the difference is "Add Existing User" and "Register User". Other
than that, they should be the same.
As you described it, I got the impression that the first owner would be
special to the process of the loading a new protocol plugin. If I
understood that wrong then we probably mean the same.
Just one thing I would like to caution against... having factories are
nice, but there can be such a thing as factory overkill. Not saying
that we are there yet, but just advising against everything being a
factory. There are situations that are good for them, then there are
some that aren't. We just have to discuss what we expect from the
parts of the system to figure out the best implementation.
It doesn't have to be factories, replace "factory" in my text with any way
to get instances of the protocol handlers from the plugins.
I thought factories was the thing to use so I wrote it like that that.
/Anders
