[vdr] Feature request: suggestion for cPlugin

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sat Aug 20 16:40:52 CEST 2005

Clemens Kirchgatterer wrote:
> Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de> wrote:
>>>Ok, I'll come up with another idea: Why not call it a message
>>>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.
> i once designed a RPC library that supported both semantics you describe
> here. there were RPC::Functions and RPC::Messages. the difference was
> that messages were simple one way atoms, though could be sent ither way.
> functions on the other hand, were strictly syncronous, and the caller
> was blocked, until the "service provider" sent back the return argument.
> in the vdr context, this would be even simpler, as there is no network
> magic needed to make things work reliably. for example (keeping udos
> syntax):
> cPluginManager::SendMessage(PluginID dest, MsgID msg, void *data)
> cPluginManager::BroadcastMessage(MsgID msg, void *data)
> cPluginManager::CallFunction(void *ret, PluginID dest, FnID id, void
> *data)
> i think other rpc-implementations do things similar, like D-BUS, DCOP.
> so despite the fact that somebody might confuse cPlugin::Messages with
> OSD::Messages, i think the term "Messages" fit well into this context.

Well, it's the same as always - if you start discussing such things as
naming stuff, things get tedious... ;-)

I'll give up - name it whatever you want and make it whatever you like.
I won't be needing nor using this stuff, anyway, so what do I care.


More information about the vdr mailing list