This weeks meeting log is attached. Mostly discussion on how plugins should be loaded and such. Inspired me to create http://trac.licq.org/wiki/DeveloperArea/PluginApi/Basics so that we all use the same lingo :)
// Erik -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! Erik Johansson http://ejohansson.se
14:02 <@erijo> anyone present? 14:02 < flynd> I'm here 14:04 <@erijo> flynd: howdy 14:05 < flynd> I guess we're the only ones here 14:07 <@erijo> i'm in the process of adding the document describing loading and unloading of plugins to the wiki 14:07 <@erijo> once i've done that, i'll jump into the mail thread on owners ;) 14:08 < flynd> ok, I was wondering why hadn't joined the owner-discussion yet 14:10 <@erijo> yeah, sorry about that. I've been too tired all week 14:12 <@erijo> but i have been thinking about what we discussed last week 14:13 < flynd> if you've read the mails from the owner-discussion then you've gotten some more details of how I think the plugin interface should work 14:14 <@erijo> there is a problem with plugins registering with the daemon to handle e.g. icq 14:15 <@erijo> they are not loaded until they are need. And when they are loaded, they are done so to handle a specific protocol 14:16 <@erijo> an example may be better at explaining it than i am 14:16 < flynd> As I see it, if a protocol plugin is not loaded then you don't have that protocol in licq and can't use or see it anywere 14:18 <@erijo> when the daemon starts, it loads all libraries (i.e. all plugins) and gets the plugin description from them (name, description, etc.) and then unloads all of them (in reality, only the unused once) 14:19 <@erijo> then, when it's time to load qt-gui, it scans the descriptions, looking for name == qt-gui 14:19 <@erijo> when it is found, the library is loaded, a plugin instance created and then run 14:19 <@erijo> then the user chooses to add a new icq owner 14:20 <@erijo> qt-gui ask the daemon to load the icq plugin 14:20 < flynd> if the plugin name, version and description is put in a separate file you would not have to load the library just to check what the plugin is 14:20 <@erijo> the daemon loads the correct library, creates a new instance and returns a plugin id to qt-gui 14:21 <@erijo> the gui can then communicate directly with the plugin, creating a new owner 14:22 < flynd> ok, my version: the config for the daemon contains a list of plugins to load, these are always loaded on startup and stays loaded even if none of their functionallity is used. Plugins can be loaded/unloaded by using the plugin manager in the UI 14:23 < flynd> if the icq plugin is not loaded, the icq protocol is not available for use, icq is not selectable for the user at the daemon (and UI) does not know about it. 14:25 <@erijo> but how will the user be able to add an icq account then? 14:26 < flynd> this means that to start using a new protocol the user must both load the plugin and register the user as two separate actions but this is how most other IM's work (example Miranda) so I don't think it is a problem when looking at useability 14:27 < flynd> if the user has enabled a plugin once, it will be loaded on startup and stay loaded always until the daemon shuts down or the user choose to unload that plugin 14:28 < flynd> as I've said earlier, I'd like to separate the protocol handling from the plugin handling as much as possible to avoid giving the protocol plugins special treatment from other plugins 14:30 < flynd> For useability, if a new plugin is found on startup, the UI could ask the user if this plugin should be enabled and if the user selects yes, the plugin wil then on always be loaded and the functionallity/feature/protocol/etc always available 14:33 <@erijo> i agree that all plugins should be treated in the same way, and this is how it is done my experimental branch 14:35 <@erijo> this is more a question on if plugins should be loaded explicit or implicit 14:36 <@erijo> or, can a plugin be loaded but not started or not 14:36 < flynd> I think the plugin handling should be flexible enough to allow one plugin to do multiple things, like providing multiple protocols or providing both a protocol and a gui extension 14:37 <@erijo> when you say plugin, do you mean the library or a plugin class? 14:38 < flynd> Is it possible to have more than one plugin class in the same library? otherwise I mean both =) 14:39 < flynd> if the user has configured licq to use a plugin, then it should be automatically loaded and started when the daemon starts. Plugins that are found but not configured to be loaded could either be just loaded to get information and then unloaded or the information could be stored in another file (with similar name to the lib) and the libryra would not have to be loaded at all. 14:41 <@erijo> a library contains one (and only one) plugin factory that is capable of creating any number of different plugins 14:42 <@erijo> and for each plugin, 0 or more instances of that plugin can be created 14:42 <@erijo> see http://trac.licq.org/browser/branches/erijo-dev/licq/licq/interface/pluginfactory.h 14:42 < flynd> A plugin that is enabled (and with this I mean that the user wants to have this plugin running) should be started but this doesn't automatically mean that it will do anything. As I described in the mails the plugin may simply just register the protocol and then lie dormant until an owner is created. 14:43 < flynd> hmm... when do you need multiple intsances of the same plugin loaded? 14:43 <@erijo> e.g. multiple icq accounts 14:44 < flynd> there will be multiple instances of the icq protocol yes, but why does the plugin have to be instanciated multiple times for that? 14:46 <@erijo> it should make it easier to write the plugin 14:48 < flynd> a simple protocol plugin would just have a small plugin class that just register a factory for the protocol handler, when an owner is loaded a protocol handler is created from the factory and from there on it won't be any difference in the plugin 14:49 < flynd> if the plugin has multiple protocols the plugin class will instead do multiple calls to registerProtocol() to provide a factory for each protocol 14:51 < flynd> a plugin with both protocol and other functionallity will do a registerProtocol() and then continue with the other stuff as if it was a non-protocol plugin 14:51 < flynd> replace registerProtocol() with what ever the plugin-api call to register a factory would be called 14:52 <@erijo> brb 14:53 < flynd> in the case with a complex plugin you might not want to have multiple instances of the non-protocol functionallity but still have multiple owners with that protocol. Then requiring the plugin class to be instanciated multiple times would make things messy 15:10 <@erijo> to me, a plugin does one thing and one thing only. There's no concept of complex plugins. But a developer can choose to bundle several plugins in the same library, and perhaps share a single instance behind the scene. But as far as the daemon is concerned, they are all different plugin instances. 15:11 <@erijo> one thing i'm planning on adding to a plugin's information, that resembles your protocol handler, is a "service" field 15:12 <@erijo> it would be e.g. icq or msn 15:13 <@erijo> so other plugins can create a "icq" plugin and then attach an owner to it 15:14 < flynd> does this mean that the plugin class will have an interface with a lot of protocol handling specific functions? 15:16 < flynd> and what do you mean with "other plugins can create a icq plugin"? shouldn't the daemon be responsible for creating and managing all protocol instances (or plugin instances)? 15:20 < flynd> with the possible exeption of the first time licq is run, owners will normally created on startup from the configuration files. Do you mean that the daemon will not be responsible for reading the owner config and connecting them with plugins/protocol instances? If so which plugin should do this? 15:20 <@erijo> yes, the daemon will create the plugin instances, but it will do so on request from another plugin (or at startup). I should have said: other plugins can ask the daemon to create a "icq" plugin 15:21 < flynd> ah, I see "at startup" as the normal case and "on request from another plugin" as a special case as licq will most likely start up moro often than the user will and and remove owners 15:23 < flynd> then we mean the same, the user must of course be able to request (via a UI) that a new owner should be created but that doesn't mean it is the responsibility of the UI to actually create and setup that owner 15:24 <@erijo> exactly 15:26 < flynd> I'm trying to compare what we are saying here... my version of a plugin is on the library level, your version of a plugin is more or less equal to my protocol instance, from there on I think we have the same idea(?) 15:28 < flynd> but will any other plugin type than protocols actually be useful to have more than one instance of? 15:29 <@erijo> as you might remember, that was one question i had last week ;) 15:29 < flynd> now that you mention it, yes I remeber =) 15:31 < flynd> how will you handle things on the library level (where I want to have the plugin class)? is there any way to run some code or have an interface to a class that is only instanciated once for the library? 15:33 < flynd> before any owners are created you have no intances of your plugins created (right?) so somewhere on the library level you must have a way to specify which plugins are available and what services they provide 15:35 <@erijo> after the daemon has loaded the library, it executes a function in that library that returns a pointer to the factory for that library. This factory is then responsible for creating the plugins 15:35 <@erijo> and the plugins created by the factory can be of any kind, the daemon does not care 15:36 < flynd> can you get any information about the plugins before you instanciate them? 15:36 <@erijo> yes, the factory can return information about all plugins it can create 15:37 < flynd> ok, so the factory is a class? I have always thought it as a single function call 15:38 <@erijo> yes, this might be helpful: http://trac.licq.org/browser/branches/erijo-dev/testplugin/src/pluginfactory.cpp 15:38 <@erijo> it is a pretty simple pluginfactory 15:38 < flynd> but if you don't create instances of protocol plugins until an owner is created then this factory must be able to return information about the protocols 15:40 < flynd> or you must create an icq plugin instance just to see what it is, then destroy it and then create a new one when the actual icq-owner is created 15:40 <@erijo> which information do you mean? 15:42 <@erijo> is it anything else besides a name and a short description? 15:42 < flynd> name of the protocol and maybe something more descriptive for the UI (could be more but I can't think of it now) 15:43 <@erijo> take a look at the link i mentioned above 15:44 < flynd> even having a bool saying which plugins are protocols plugins and which are not I see as having protocol info in the plugin interface 15:44 < flynd> ok, I'll check th link now =) 15:46 < flynd> couldn't see any protocol info there, so what will stop me from creating an owner using protocol "qt-gui"? =) 15:46 < flynd> nm, I missed PluginTypeGeneral 15:47 < flynd> but then we are back to having protocol-specific things in the plugin interface 15:48 <@erijo> i see that as a way for guis to exclude protocol plugins in their plugins list, and exclude anything but protocols in the owner manager dialog 15:50 <@erijo> they are still loaded and started in the same way 15:51 < flynd> why exclude the protocol plugins from the plugin list? 15:52 <@erijo> ok, perhaps there no point in excluding them from the plugin list, but i still think there's a point in excluding e.g. the history plugin from the owner manager dialog 15:53 < flynd> even if this makes all plugins the same type down at the plugin level they will still ha handled in differently all the way so logically there are still two types of plugins just like in licq 1.3 15:54 < flynd> well, yes of course protocols must be in a separate list for just that reason 15:54 <@erijo> i don't see the problem. Wasn't your point that they should be handled the same down at the plugin level? 15:54 < flynd> I'm trying to think whether this could be a limitation in the future, I'd still like to separate plugins and protocol handling more... 15:55 < flynd> this just mean that they are loaded the same way, after that they are still different 15:56 <@erijo> well, they are different 15:57 <@erijo> but they will be loaded, started and get messages the same way 15:58 <@erijo> (i.e. they will all have an event queue [or message queue]) 15:59 < flynd> in my version a plugin provides a service in the form of a protocol, in your version the plugin is the protocol 16:01 < flynd> I'm not sure I see any actual problems with your design, it just doesn't fit with how I picture these things and I'm unsure if it will be a problem in the future or not to remove one layer from my version to get to what you have 16:02 < flynd> I wish there would be a bunch of people to either say I'm right or tell me to shut up =) 16:02 <@erijo> in my version a plugin factory provides services, e.g. an icq protocol and an aol protocol. These services are then provided in a the form of a plugin 16:03 <@erijo> instance 16:14 < flynd> I think I'll drop the subject for now, but I have better view of your design than I had earlier. I'll think it through a bit and maybe continue this another time =) 16:14 < wuhuu> hello! 16:14 < flynd> hello 16:15 < wuhuu> i have a problem: everytime someone who got ICQ 5.1 answers me is see him typing and then he goes in dnd-mode 16:16 < wuhuu> and i don't get any message from him/her 16:17 < wuhuu> i'm using the actual SVN-version but i have the same problem with 1.3.4 16:18 < flynd> It is a known problem, from what I can see work is ongoing: http://trac.licq.org/ticket/1445 16:36 <@erijo> flynd: http://trac.licq.org/wiki/DeveloperArea/PluginApi/Basics 16:37 <@erijo> so we can use the same lingo when talking :) 16:40 < flynd> is it on my end or is trac slow again? that page took like 10 sec to load 16:41 <@erijo> the load is < 0.2 16:42 < flynd> well opera has been running for almost 2 months, maybe it's time to restart it =) 16:45 <@erijo> time for me to go. see you later 16:45 < flynd> bye
pgpi9QkginHdX.pgp
Description: PGP signature
