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
