[vdr] Feature request: suggestion for cPlugin

[Klaus Schmidinger]

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