Presentation of LibIPC: a few improvements.

master
Philippe Pittoli 2023-01-20 04:49:45 +01:00
parent 06a01f2b4b
commit 82f81a7fb7
1 changed files with 35 additions and 14 deletions

View File

@ -11,17 +11,40 @@ Network code separation
* networking: performed by dedicated services
* other applications: think all communications are local
#pause
Library code separation
* make libraries language independent
* micro-services are great, each of them does its part
#pause
why not on base systems?
#pause
Applications are better than libraries
* implementations change
* languages change
* API… not so much (not as often at least)
## In practice
usage must be simple
1. init connection or service
2. loop over events
#pause
events are simple and high level
1. connection and disconnection
2. message received and sent
## When
LibIPC is useful when the app:
- cannot be a simple shell command
- needs a bidirectional communication
- is an abstraction over a library
## Available libraries
* libevent
@ -54,22 +77,23 @@ Is it designed *NOT* to be used?
* documentation isn't great
* no code example
And kinda obsolete: a big chunk of the documentation is
## DBUS (bonus page!)
DBUS feels obsolete: a big chunk of the documentation is
about message format. Just use CBOR already!
#pause
They even admit they did a poor job on the C part:
> There is a low-level C binding, but that is probably too detailed
> and cumbersome for anything but writing other bindings.
#pause
Oh. And C++. YOU SHALL NOT PASS!
This is a Linux requirement nowadays, wth?
## Bare libc api
All have great performances
shared memory and semaphores
* (kinda) complicated api
@ -80,8 +104,11 @@ pipes, sockets
* lack a conventional message format
... but that's about it
Great to start with!
* Great to start with!
All have great performances to exchange data.
What is slow is the function to _wait_ for new events.
## LibIPC history
@ -100,17 +127,11 @@ pipes, sockets
#pause
3. rewrite using poll(2)
* many bugfixes later, way more tested than before
* implementation now kinda production-ready
* enough for altideal.com at least
* implementation was kinda production-ready
* implementation was simple: < 2000 lines of C code
## Current implementation of libIPC
implementation is simple: < 2000 lines of C code
usage is simple
1. init connection or server
2. loop over events
bindings are available in Crystal
* as well as fancy mappings: JSON and CBOR class serialization