On Feb 22, 1:48 am, "Anders Olofsson" <[EMAIL PROTECTED]> wrote: > 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.
Perhaps Erik can chime in? I agree, it would be nice to allow the plugins to be basically the same. With the code in erijo-dev, it appears to be that way now. But anyways, yes, I agree with you about this. > 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. Alright, sorry, I thought you were saying something else. > 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'll work on improving the document to make the distinction clearer. And to go into more detail about a previously configured Licq. > ini-file) I therefore wrote "xml-block" to refer to that data in whatever > form it will be runtime. I was just visualizing passing around an XMLStream or something. > 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. So in otherwords, don't run StartPlugin (or whatever it will be called)... > 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.) Agreed. > 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. Well, it sounds like it will be good for user registration, at this point. Just was a caution in general. Jon
