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...
> 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?
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 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).
> 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?
> 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.
> 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
Yes, perhaps a Factory would make it easiest. Like, when you go to the
next step just call the next() method in the factory. I haven't given
any restrictions on implemention, just defining what it should do.
After we decide how owners should be handled, we can get down to the
implementation details, but it sounds like we are already...
> It should also be possible to have a protocol implementation that cannot
> register new users for some reason.
Yes, the protocol plugin will have to have a way of saying that it
doesn't do that.
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.
Jon
