Klaus Schmidinger wrote:
My original arguments regarding the use of dedicated functions were dismissed, saying that this would require including header files for definitions.
As far as I can tell, Martin's argument is the k.o. criteria for this, as access to member functions requires both plugins to share a linker symbol context. Sharing just the headers imho only gives access to member variables and virtual methods derived from cPlugin. One could use a function pointer, but thats not really elegant.
Well, if you take a look at Udo's example plugins, there is struct ReportBoredPlugin struct AddService in both of them. So there's a code duplication right there, and if the server decides to change something, the client will have to change it's code as well. It will be fun to watch this stuff go through protocol changes... ;-)
A dedicated struct is a lot safer than the whole class, as it wont change that frequently. And the documentation will clearly warn, that any change to the struct requires changing the ID string too.
Hmm, still no "oh yes!" feeling here.
Maybe my original "service" suggestion isn't that obsolete, yet.
Ok, I'll come up with another idea: Why not call it a message interface?
cPluginManager::SendMessage(...) cPluginManager::BroadcastMessage(...) cPlugin::ProcessMessage(...) or cPlugin::Message(...)
So personally I'd vote for not implementing CallPluginService(), but if you absolutely insist, I won't argue any more.
Since most people think it is not needed, I agree to drop it. I've added it only for completeness anyway.
Cheers,
Udo