Clemens Kirchgatterer wrote: > 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. 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. Klaus
