I suppose when I think of validation, I think of something as either being correct or not. With RPC it's immediately clear when a client call does not fulfill the contract with the server.
In the case of messaging, a message with "incorrect routing information" would just not reach a destination. Even saying routing information is incorrect is not really...correct. I would say the message routing is parsed and it either gets directed to a destination or it doesn't...It's not valid or invalid really, it just doesn't meet any criteria to reach a destination. It's not going to raise an error on the broker, it's just going to be ignored or may end up in a default destination if one has been configured. It's a subtle difference but it's part of the "forgiving" nature of messaging. On Mon, Jun 2, 2014 at 11:19 AM, Marcus Ottosson <[email protected]> wrote: > Hmm. Do you include “validation of messages” when you mean “validation”? > > Consider this: > > >>> proxy.send({'do': 'make me a sandwich', 'with': 'mustard, and tomatoes', > >>> 'toasted?': 'yes'}) > > Here, a message is being sent, but not to a procedure. Could we consider > this a non-RPC call? > > In this case, there will be a receiver (the router) and the router MAY > forward the call to a worker. But let’s say it doesn’t. > > Still, the message will have to be interpreted. The message is routed > based on the routers interpretation, no? This interpretation is what I’d > consider a form of validation. > > A router may be able to accept any message, but it will always try and > make sense of it, before discarding it. > > It feels like we’re talking about the same thing, but if you’d rather not > call it “validation”, what would you call it? > > > > On 2 June 2014 16:12, Tony Barbieri <[email protected]> wrote: > >> When using RPC the server may also validate it when the call comes in. >> Your example above of pre/post validation basically refers to RPC and only >> RPC. If the client can validate a RPC call before sending it will (in the >> case of some python RPC frameworks, this is the case). If the client can't >> validate the call then the server will validate it when it receives the >> request. >> >> In the case of messaging there is never any validation. A consumer MAY >> throw an exception of some kind, but first a consumer would have to pick up >> the message and do something with it. Messages may not even be tasks to be >> executed. In the case of Celery they are tasks that have methods/functions >> that will be executed on a worker but Celery is leveraging message based >> systems to work that way and it is not inherit to a message based system. >> >> >> >> On Mon, Jun 2, 2014 at 11:00 AM, Marcus Ottosson <[email protected]> >> wrote: >> >>> Ok, how about this. >>> >>> At one point or another, a message is translated into a procedure (let's >>> assume the procedure exists). In the case of RPC, the translation isn't >>> dealt with until the signature is validated from the client. I.e. the >>> client must be aware of the signature, prior to allowing anything to be >>> sent across the wire. >>> >>> In the other case, a message is sent regardless and the client has no >>> prior knowledge of what is valid and what is not, but will be informed of >>> it after the fact. In this scenario, a message is always sent across the >>> wire, and the client may or may not get a return value or exception. >>> >>> Does that sum it up? >>> >>> >>> On 2 June 2014 15:43, Tony Barbieri <[email protected]> wrote: >>> >>>> I think the difference between RPC and a message based system is not >>>> whether pre or post validation occurs, but rather if validation ever >>>> occurs. >>>> >>>> When using messaging, the message will go to the broker no matter what. >>>> What happens to that message once it lands in the broker is up to the >>>> broker settings and if there are any consumers subscribed to the broker in >>>> such a way that they would be notified of the message. pre/post validation >>>> does not come into play in that scenario. >>>> >>>> It does come into play when using RPC in that either the client will >>>> validate if the server can handle the request or the server will figure out >>>> if it can handle the request. If either determines the request can not be >>>> handled, an exception will be raised immediately. >>>> >>>> In a messaging system the client is required to care if the message was >>>> handled or not either via timeouts or by pinging for the result/status of >>>> the message. >>>> >>>> >>>> On Mon, Jun 2, 2014 at 10:26 AM, Marcus Ottosson < >>>> [email protected]> wrote: >>>> >>>>> Cool, thanks Tony. I think it’s perfectly fine to have your own >>>>> definitions, but for the sake of this conversation, it would be really >>>>> helpful if we can all referred to the same thing. >>>>> >>>>> Sounds like we’ve got two definitions going on, let’s find a more >>>>> appropriate wording for them: >>>>> >>>>> 1. Signature defined prior to sending a message across the wire, >>>>> pre-validated >>>>> 2. Signature defined after being sent, post-validated. >>>>> >>>>> *pre-validated* >>>>> >>>>> Where the signature must match the Python stdlib “json” module >>>>> >>>>> >>> proxy.json.dumps({"c": 0, "b": 0, "a": 0}, sort_keys=True) >>>>> >>>>> *post-validated* >>>>> >>>>> Where signature may differ, so as to be fit for multiple languages >>>>> even those without the ability to sort the keys. The receiver decides what >>>>> to use. >>>>> >>>>> >>> proxy.send( >>>>> {'address': 'json', >>>>> 'payload': {"c": 0, "b": 0, "a": 0}, >>>>> 'sortKeys': True} >>>>> ) >>>>> >>>>> It’s an amazingly interesting topic, as it relates to where to put the >>>>> responsibility; on the user, or the recipient. >>>>> >>>>> Do the examples make sense, is this what we’re referring to? >>>>> >>>>> >>>>> >>>>> On 2 June 2014 14:43, Tony Barbieri <[email protected]> wrote: >>>>> >>>>>> It enables a system to make calls to programs such as NFS across the >>>>>>> network transparently, enabling each system to interpret the calls as if >>>>>>> they were local. - Definition of RPC >>>>>>> <https://www.google.co.uk/webhp?sourceid=chrome-instant&rlz=1C1CHFX_en-GBGB568GB568&ion=1&espv=2&ie=UTF-8#q=define%20rpc> >>>>>> >>>>>> >>>>>> Not to continue the debate but I am using messaging to perform tasks >>>>>> much like that definition ;). For example, when a worker picks up a task >>>>>> it will execute the code on the machine the worker is running on which >>>>>> may >>>>>> end up invoking the procedure call remotely if the worker is running on a >>>>>> remote machine. >>>>>> >>>>>> I think the biggest difference between RPC and messaging is what >>>>>> Justin outlined above: >>>>>> >>>>>> But to me, the RPC aspect is that it presents a predefined interface. >>>>>>> A function with a signature. This signature is validated as part of the >>>>>>> RPC >>>>>>> implementation before it goes onto the wire. >>>>>> >>>>>> >>>>>> With messaging, no validation happens in regards to the message >>>>>> contents. The message is sent off to the broker and if there is a >>>>>> worker/consumer present that can deal with that message it does so. If >>>>>> there is not a consumer present that knows how to deal with the message >>>>>> then nothing happens unless either a timeout occurs or a consumer comes >>>>>> online that can deal with it. With RPC you have an explicit contract and >>>>>> at the time of invoking the RPC call, the call signature will be >>>>>> validated >>>>>> either client side or server side. If a contract was never created for >>>>>> the >>>>>> call signature an exception will be raised right then. >>>>>> >>>>>> This is that what I consider the major differences between RPC and >>>>>> messaging are... >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 2, 2014 at 2:10 AM, Marcus Ottosson < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I feel it is an implementation detail and not the sole definition of >>>>>>> RPC >>>>>>> >>>>>>> I think this is where we went off the rails. >>>>>>> >>>>>>> It enables a system to make calls to programs such as NFS across the >>>>>>> network transparently, enabling each system to interpret the calls as if >>>>>>> they were local. - Definition of RPC >>>>>>> <https://www.google.co.uk/webhp?sourceid=chrome-instant&rlz=1C1CHFX_en-GBGB568GB568&ion=1&espv=2&ie=UTF-8#q=define%20rpc> >>>>>>> >>>>>>> From now on, let’s refer to RPC as being this, ok? :) >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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/CAFRtmOCs7mvdqVbcwBgsbfBR-G_k72kny1hvCubD%2BOXtTwNkRw%40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCs7mvdqVbcwBgsbfBR-G_k72kny1hvCubD%2BOXtTwNkRw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -tony >>>>>> >>>>>> -- >>>>>> 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/CAJhmvsQbE2gZvod9fiq0_ea2ggx4NobhtMVOiYkr2qcBiGXxoQ%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsQbE2gZvod9fiq0_ea2ggx4NobhtMVOiYkr2qcBiGXxoQ%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/CAFRtmODNjPaDwX8RTM9G0-OPWojvKTgQ%2BO_%3Dwv8xOgm2Mc8oVQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODNjPaDwX8RTM9G0-OPWojvKTgQ%2BO_%3Dwv8xOgm2Mc8oVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> -tony >>>> >>>> -- >>>> 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/CAJhmvsRhEpnxbTjUB%2BisEO6YQjc2iNz925-TCZgK1gyD-GJZzA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsRhEpnxbTjUB%2BisEO6YQjc2iNz925-TCZgK1gyD-GJZzA%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/CAFRtmOAY-nzbNkcDeGWgD8csFrNqRt2vFzbA9%2BeSpzgQO4-ogg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAY-nzbNkcDeGWgD8csFrNqRt2vFzbA9%2BeSpzgQO4-ogg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> -tony >> >> -- >> 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/CAJhmvsRziUB%3DbA8218oV_RTw1KDYyRTd9-BJNTXkqERtEnsKjw%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAJhmvsRziUB%3DbA8218oV_RTw1KDYyRTd9-BJNTXkqERtEnsKjw%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/CAFRtmOCRskXXaW%2BWE6AR0hRZJG2h1wJc%2BtUdqppCxPW%2BsYXwxg%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCRskXXaW%2BWE6AR0hRZJG2h1wJc%2BtUdqppCxPW%2BsYXwxg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- -tony -- 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/CAJhmvsQw3RcNbjnDnsYCm_tcrrUrjxoFgX%3DBRmFsG8TUr99skA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
