Christian Wieninger wrote:
> Hi,
>
>> You also might want to give some guidelines as to how to create
>> those "ServiceIDs" - otherwise most likely every plugin will come
>> up with a totally different scheme.
>
>
>>
>> Klaus
>
>
> I also think this should be done, and atleast a version info has to be
> part of the interface to avoid problems with changed protocols in newer
> plugins. Udo made it part of the service string itself in his sample
> plugins.
> Perhaps it should be a separate value. Don't know ;-)
Well, I'll leave that to Udo ;-)
My original arguments regarding the use of dedicated functions were
dismissed, saying that this would require including header files for
definitions. Well, if you take a look at Udo's example plugins, there is
struct ReportBoredPlugin {
cPlugin *BoredPlugin;
};
struct AddService {
int a,b;
int sum;
};
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... ;-)
> Since this interface can not only be used to call a service of the
> server plugin,
> but also to broadcast a message from the client to possibly many servers,
> this should also be considered with respect to the naming problem.
>
> Some suggestions:
>
> - CommunicationInterface
> - InterchangeInterface
> - ExchangeService
Hmm, still no "oh yes!" feeling here.
Maybe my original "service" suggestion isn't that obsolete, yet.
What drove me off of it was the "ServiceID", which is already used
for something completely different. But the generic word "service"
should still be able to be used.
So how about this:
cPlugin:
virtual bool Service(const char *Id, void *Data = NULL);
cPluginManager:
static cPlugin *CallFirstService(const char *Id, void *Data = NULL);
static cPlugin *CallPluginService(const char *PluginName, const char *Id, void *Data = NULL);
static bool CallAllServices(const char *Id, void *Data = NULL);
Actually CallPluginService() should be superfluous because the caller could
first get the plugin by name and then call its Service() function (thus allowing
it to actually know whether there is such a plugin at all).
So personally I'd vote for not implementing CallPluginService(), but if you
absolutely insist, I won't argue any more.
Klaus
