Klaus Schmidinger <Klaus.Schmidinger@xxxxxxxxxx> 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 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. clemens
