Udo Richter wrote:
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.
Ok, let's end this - there shall be those functions you suggested.
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(...)
Well, "Message" IMHO implies that this is sort of a one way thing, while "Service" can go either way. In your example you have a plugin that adds numbers. Now if a client "sends a message" to that server, saying "add 2 and 3", the server might think "well, nice message". OTOH if the client "requests the service" of "add 2 and 3", this (at least to me) implies much more that there is a result to be expected.
If I'm not mistaken the whole point of this interface is to allow one plugin to make use of a service provided by another plugin. Therefore I'd still consider "service" the better choice.
Klaus