Ah I was referring to your question above that sparked the RPC discussion -
Tony
Hmmmmmm. :) Ok, for this, let’s try and define what we mean with RPC.
Here’s what I mean:
*RPC call, where proxy represents a remote machine*
# Local>>> proxy.log.info('hello world')
# Remote>>> log.info('hello world')
Here, log.info is the name of the function called on the other side. If the
function does not exist, you get an AttributeError. There is a 1-1
correspondence between caller and receiver. Like we would expect, from a
local call in traditional, imperative programming languages such as Python.
Tony, when you say you’ve worked with messaging without RPC, how does
something like that look? And Justin, how does it look for you?
What do you guys think about this for differences?
http://www.inspirel.com/articles/RPC_vs_Messaging.html
Personally I would prefer not to talk in terms of “patterns” as that sounds
very java-minded (command pattern, actor pattern, …), and boxing you into
thinking about what you can and cannot do. - Justin
I’m not sure you’ve got the right idea here. Patterns have little to do
with languages, nor about what you can or cannot do. A pattern, as far as I
can tell, is a description of a scenario, coupled with pros and cons and a
name so that we can refer to it in general conversation.
Are we talking about something like this?
http://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612
Also, where did “patterns” enter into the discussion? Do you consider RPC a
pattern? On the contrary, patterns can be used to implement RPCs, like
the Proxy
Pattern <http://en.wikipedia.org/wiki/Proxy_pattern> and the Abstract
Factory Pattern <http://en.wikipedia.org/wiki/Abstract_factory_pattern>.
On 31 May 2014 22:58, Justin Israel <[email protected]> wrote:
>
> On Sun, Jun 1, 2014 at 9:39 AM, Marcus Ottosson <[email protected]>
> wrote:
>
>> I think both ways work great
>>
>> Aw, that’s no good. :) I’m looking for actual cases where one is more
>> appropriate than the other, not which one is the silver bullet of computing.
>>
>> It’s a discussion on distributing work via a chat-like interface, not
>> very generalised I’d think, but if you’d like let’s throw in some numbers:
>>
>> In the conversation, there’d be around:
>>
>> - 500 peers in total
>> - 50 of them being active within any given second
>> - within which 2 tasks are being distributed continually
>> - Tasks are at the size of “hello world”, “create directory”, “list
>> directory”, “write metadata”, “add 1 to 1” etc..
>> - ..each taking up a maximum of 1 second each.
>>
>> Personally I would prefer not to talk in terms of "patterns" as that
> sounds very java-minded (command pattern, actor pattern, ...), and boxing
> you into thinking about what you can and cannot do. I see RPC as just a
> formalized layer of message passing. Under the hood you have a socket
> sending a message, and someone on the other side receiving the message, and
> sending a reply. The difference is that RPC puts you firmly into a
> request-reply situation, where the reply may not even be for the computed
> answer. The reply could just be an id for which the caller could use as a
> promise to then poll for the computed result at a later date.
> Using a pure message passing framework like ZeroMQ, as you already know,
> gives you the tools to implement more communication types like push-pull,
> and pub-sub. If these types of communication are important to your
> application, then RPC is probably not the single solution. It can
> definitely be used for a client to talk to a server, and then a server can
> use features of zmq to talk to workers. But in terms of the client talking
> to the server, I would see RPC or lower level message passing being pretty
> much the same camp. Either you are directly sending the structured message,
> or you are using a predefined interface that will send your message based
> on parameters. Either you want to wait for the answer or you don't.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2SdTHud6bCeipDSScTkUei-MpEz3uXJOC1AX94Z2Kadg%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2SdTHud6bCeipDSScTkUei-MpEz3uXJOC1AX94Z2Kadg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
*Marcus Ottosson*
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBmV3JA6S96nWAH-SJ2iPiwfLFQ6L-LzL%2Bjd1t8Mcc20Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
