[vdr] Feature request: suggestion for cPlugin
clemens at 1541.org
Sat Aug 20 16:27:53 CEST 2005
Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de> wrote:
> > 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.
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
cPluginManager::SendMessage(PluginID dest, MsgID msg, void *data)
cPluginManager::BroadcastMessage(MsgID msg, void *data)
cPluginManager::CallFunction(void *ret, PluginID dest, FnID id, void
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.
More information about the vdr