Yes, what you wrote makes sense. Promises are part of the Celery framework and not part of the specifications of messaging.
Promises are there, but they don't have to be used. Celery could be thought of as a type of RPC I suppose in that each celery task does refer to a procedure that will be most likely be executed by some remote worker. With standard RPC, the calls are typically validated either client-side or server-side and then executed on the machine running the RPC server if found valid. This is not necessarily the case with messaging in that there is no concept of validation and the message just goes to the broker which will decide where it should go. The promises used by celery are a convenience that may be used to react to some result of a task being processed. They can just as easily be dropped on the floor and completely forgotten about. They can be used in cases where you need to perform a synchronous call and wait on a result (folder creation is an example). Another use case is to use them in a thread where you want to display to the user some result of a message by polling the promises periodically to check if there is a result/error. You could also use a callback to immediately be notified when a resolution has occurred. Promises offer an extra layer to be used as you will, but you are correct in saying they are part of the Celery framework in this instance. On Mon, Jun 2, 2014 at 11:07 AM, Marcus Ottosson <[email protected]> wrote: > Sorry, I shouldn't have used the word RPC. :) I get that you're using > Promises in your message handling, which blurs the line between what is > messaging and what is pure RPC. According to Google, an RPC looks *exactly* > like a local call. But, in the case of getting a promise in return, this is > completely unique to the messaging framework (Celery, in this case) and is > not what you would get if the call were local (if we stay simple, I know > there are uses for promises in local calls too). > > Does that make sense tho? > > > On 2 June 2014 16:00, 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] >> > > > > -- > *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/CAFRtmOCTuvxBvi7z6bzOv3qevtdRNM1bGzfnTmL9w9Q_GGMJig%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCTuvxBvi7z6bzOv3qevtdRNM1bGzfnTmL9w9Q_GGMJig%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/CAJhmvsQqWimteg_XwGrDqvOJ3zQFd7%3D41of8HMF-4nEE%3Dy02Ag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
