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
