aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/os/msgpack_rpc_helpers.c
Commit message (Collapse)AuthorAge
* msgpack-rpc: Create subdirectory for msgpack-rpc modulesThiago de Arruda2014-10-21
| | | | | Create the msgpack_rpc subdirectory and move all modules that deal with msgpack-rpc to it. Also merge msgpack_rpc.c into msgpack_rpc/helpers.c
* api/msgpack-rpc: Refactor msgpack_rpc_helpers.{c,h}Thiago de Arruda2014-09-12
| | | | | | - Move helpers that are specific to API types to api/private/helpers.{c,h} - Include headers with generated declarations - Delete unused macros
* api/msgpack-rpc: Remove Position type, using arrays instead.Thiago de Arruda2014-09-12
|
* api/msgpack-rpc: Use EXT type to serialize Buffer/Window/TabpageThiago de Arruda2014-09-12
|
* api/msgpack-rpc: Remove specialized array typesThiago de Arruda2014-09-12
| | | | | | | | | | | | | | | | | Specialized array types(BufferArray, WindowArray, etc) were added to the API for two main reasons: - msgpack used to lack a way of serializing appliaction-specific types and there was no obvious way of making an API function accept/return arrays of custom objects such as buffers(which are represented as integers, so clients didn't have a way to distinguish from normal numbers) - Let clients in statically-typed languages that support generics have a better typed API With msgpack 2.0 EXT type the first item is no longer a factor and this commit starts by removing the specialized array types. The second item will be addressed in the future by making the API metadata return extra useful information for statically-typed languages.
* msgpack-rpc: Refactor initializer and dispatcherThiago de Arruda2014-09-12
| | | | | | | | Use Map(String, rpc_method_handler_fn) for storing/retrieving rpc method handlers in msgpack_rpc_init and msgpack_rpc_dispatch. Also refactor serialization/validation functions in the msgpack_rpc.c/msgpack_rpc_helpers.c modules to accept the new STR and BIN types.
* deps: Update to the experimental msgpack v5 branchThiago de Arruda2014-09-12
| | | | | | | | Using msgpack v5 will let nvim be more compatible with msgpack libraries for other platforms. This also replaces "raw" references by "bin" which is the new name for msgpack binary data type
* channel/msgpack_rpc: Refactor API dispatchingThiago de Arruda2014-06-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is how API dispatching worked before this commit: - The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer` argument. - The response is incrementally built while validating/calling the API. - Return values/errors are also packed into the `msgpack_packer` while the final response is being calculated. Now the `msgpack_packer` argument is no longer provided, and the `msgpack_rpc_dispatch` function returns `Object`/`Error` values to `msgpack_rpc_call`, which will use those values to build the response in a single pass. This was done because the new `channel_send_call` function created the possibility of having recursive API invocations, and this wasn't possible when sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly through the `msgpack_packer` instance). Since we only start to build the response when the necessary information has been computed, it's now safe to share a single `msgpack_sbuffer` instance across all channels and API invocations. Some other changes also had to be performed: - Handling of the metadata discover was moved to `msgpack_rpc_call` - Expose more types as subtypes of `Object`, this was required to forward the return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call` - Added more helper macros for casting API types to `Object` any
* channel/msgpack_rpc: Refactor to better split functions across modulesThiago de Arruda2014-06-24
Move validation/conversion functions and to msgpack_rpc_helpers to separate those from the functions that are used from the channel module