the JMAP processor's process_request is obsoleted by handle_calls
Implementing SentenceCollection means that as we're handling each method in the call, we store the Ix::Result object until the end of all methods, at which point the final collection of results can be packed for serialization by Ix::App.
results_so_far means that a method handler can see the results of methods already called. This is mostly so we can implement backrefs (JMAP spec, ResultReference), but it may have other uses. Having the sentence collection implementation means that the results-so-far are much easier to deal with.
handle_calls is almost exactly the same as process_request, but it returns a sentence collection rather than a reference to an array of packed results. Since Ix::Result objects might be specialized beyond being containers for unblessed structures, this means that handling a nested call should be less obnoxious. (Previously, standard practice was either to look up the coderef for the handler and call it manually or to use process_request and then look at something ugly like $res[1][0].
process_request is still present, and is a very small wrapper around handle_calls.
mmcclimon
commented
6 years ago
There are three distinct but related changes in this branch.
Implementing SentenceCollection means that as we're handling each method in the call, we store the Ix::Result object until the end of all methods, at which point the final collection of results can be packed for serialization by Ix::App.
results_so_far means that a method handler can see the results of methods already called. This is mostly so we can implement backrefs (JMAP spec, ResultReference), but it may have other uses. Having the sentence collection implementation means that the results-so-far are much easier to deal with.
handle_calls is almost exactly the same as process_request, but it returns a sentence collection rather than a reference to an array of packed results. Since Ix::Result objects might be specialized beyond being containers for unblessed structures, this means that handling a nested call should be less obnoxious. (Previously, standard practice was either to look up the coderef for the handler and call it manually or to use
process_requestand then look at something ugly like$res[1][0].process_request is still present, and is a very small wrapper around handle_calls.