Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Compile on demand plugin
oBFusCATed:
--- Quote from: MortenMacFly on March 03, 2012, 09:09:11 pm ---So what would be the base for the comparison then? The plugin's name, a GUID?
--- End quote ---
A special identifier not shown in the GUI, so the name of the plugin, can easily be changed.
Listing the dependencies in the manifest sounds good to me.
Alpha:
One situation to consider is what should the plugin manager do if a dependency cannot be met. I would suggest that in addition to listing dependencies in the manifest, the dependencies should be marked as optional or required. The plugin manager could use this to determine if it should cancel loading of the plugin in question, or if it should load it after meeting as many dependencies as it can.
MortenMacFly:
--- Quote from: Alpha on March 03, 2012, 11:19:04 pm ---The plugin manager could use this to determine if it should cancel loading of the plugin in question, or if it should load it after meeting as many dependencies as it can.
--- End quote ---
Well - then it becomes more and more complicated for "just" a simple load-order. Concerning the GUID, we also need a mechanism to provide one "world wide" one, also for closed source plugins. This needs the be encoded into all existing plugins, too. Sorry, but the more I think about this the more I prefer a simple weight - we can introduce this w/o affecting anything we've done already.
oBFusCATed:
Hm, why do you care about closed sourced plugins, now?
They won't load in newer version of C::B anyway, because the API/ABI is already broken since 10.05.
Also I don't think we need required/optional flags.
BTW: The plugin manager should be rewritten, because currently we read the manifest after we load the dll/so, which is slowwwwwwwwwww. (if I've not mistaken of course)
MortenMacFly:
--- Quote from: oBFusCATed on March 04, 2012, 12:20:03 pm ---Hm, why do you care about closed sourced plugins, now?
--- End quote ---
Not now, but always. My point is, that we should consider the whole impact of any change we do in that direction. And if that change requires modifying each plugin I prefer a solution which does not.
--- Quote from: oBFusCATed on March 04, 2012, 12:20:03 pm ---BTW: The plugin manager should be rewritten, because currently we read the manifest after we load the dll/so, which is slowwwwwwwwwww. (if I've not mistaken of course)
--- End quote ---
Yes - that's true, but I don't see another way as (i.e.) we need to load the plugin to verify the SDK version it is targeting as setup in the manifest file. So this would indeed need some re-factoring... I'm afraid either ways, probably... ???
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version