Obsolete
/
libipc-old
Archived
3
0
Fork 0
This repository has been archived on 2024-06-18. You can view files and clone it, but cannot push or open issues/pull-requests.
libipc-old/README.md

154 lines
5.7 KiB
Markdown
Raw Normal View History

2016-12-23 13:06:31 +01:00
# the problem
End-user applications are huge, with tons of libraries used and are a pain in the ass to maintain.
Libraries are huge, with a lot of things happening, with changes that break everything on a regular basis, with almost each time very few people working on it.
2017-01-01 18:48:06 +01:00
Libraries are written for every project, most of the code can be re-used because it is not fundamentally bounded to a single project.
Start a new project is not an easy task neither.
- What language to use?
- I am doing something already coded somewhere?
- Is this library working on every platform?
- Are the libraries I need (and the good version) available for my platform, do I need to install SomeBullshitOS or ProtoContenerizator3000 to code?
2016-12-23 13:06:31 +01:00
# how to change that ?
**Network protocols**
Network protocols are awesome: very few changes, well documented, programming language agnostics.
Don't (just) write libraries, write applications !
Your need a functionality in your application, why do you have to code it ?
Just ask a service !
**Example**
You want to download a file, you will always have the same input: a string corresponding to the file to get, such as _ftp://example.com/file.txt_.
You don't have to worry about the protocol to use in your own application, the burden is on the dedicated *downloading* service.
# benefits
**Awesome abstractions**.
You will be able to do things without any code.
* applications don't have to know if the services they use is on the network or on your own computer
* applications don't need to change anything to handle new protocols, no recompilation
* applications can be statically compiled, the memory footprint should be extremely low (yes, even for a browser)
2017-01-01 18:48:06 +01:00
Let's write *abstractions* together, and less application-specific code !
2016-12-23 13:06:31 +01:00
**Simple applications**.
2017-01-01 18:48:06 +01:00
You only need to code the specific parts of your own application.
2016-12-23 13:06:31 +01:00
The only thing your application should have to take care is its functionality, and to communicate to services providing abstractions.
**Consistency**.
Everything will be developed in the same repository: same coding standards, changes will be tested on every provided applications…
**Code review**.
We should always try to provide new abstractions, reducing the code needed in both services and end-user applications.
To that end, code review is a must.
2016-12-25 15:29:21 +01:00
**No need to rewrite everything**.
You have great libraries?
Don't redevelop them!
We can use already existing libraries to provide new functionalities to our programs: we just have to write a service and to define new messages to request it, period.
2016-12-25 16:47:55 +01:00
**Language independent**.
You have an awesome library to do X, but it's written in an obscure language.
Who cares?
Write a simple service that can be requested following our protocol, everybody will be able to use your library without painful-to-maintain bindings!
We may even assist you doing that by providing templates for your language, or check the other services!
2016-12-25 15:29:21 +01:00
**The end of "oh, I would like to dev something but this requires too much painful-to-install dependencies"**.
You only need the communication library and the service running (not even on your own computer) without any other dependencies.
That's it, you're good to go!
2016-12-25 16:47:55 +01:00
# Not adapted to everything
If you need incredible performances for your application, maybe this won't fit.
There is no silver bullet or one-fit-all solution.
Still, we think performances won't be much of a problem for most of the everyday life applications and if there are performances hits we still have plenty of room for optimisations!
2016-12-23 13:06:31 +01:00
# Application and services
- Services: daemons providing a feature (windowing, audio, network, input, pubsub, …)
- Applications: end-user applications (browser, mail user agent, instant messaging app, …)
#### examples
A browser that can download everything, via every existing protocol.
No any specific code in the browser itself and no configuration.
2016-12-25 15:29:21 +01:00
You want to play a game on your raspberry pi, but it is not powerful enough, run your application on your laptop but take the inputs from the rpi (or anywhere on the network) !
2016-12-23 13:06:31 +01:00
No specific code needed.
# TODO
Figures, a lot of them, to explain everything.
# connection init (draft)
## how things happen
1. Service creates a unix socket /tmp/service-index-version.sock
1. Application connects to /tmp/service-index-version.sock
__legend__:
- service: service name
- index: process index (to launch a service several times)
- version: service version
# pure "networking" view (what should go in the sockets)
#### connection
1. Application connects to /tmp/service-index-version.sock
1. Service acknowledges (empty message)
#### disconnection
1. Application sends a message "CLOSE" to the server
#### data
1. Application or server sends a message "DATA", no acknowledgement
# messages format
In order to communicate between the application and the service, we use the Type-Length-Value format.
This will be used with some conventions.
The type will be a simple byte :
* <0 - 15> : control, meta data
* <16 - 127> : later use
* <128 - 255> : application specific (windowing system, audio system, …)
index | abbreviation | semantic
0 | close | to close the communication between the application and the service
1 | connection | to connect to the service
2 | error | to send an error message
3 | ack | to send an acknowledgment
4 | message | to send data
2017-01-01 18:48:06 +01:00
# Services Status
Go to the relevant directory for details.
- pongd: stable
- tcpd: experimental
- pubsub: experimental
# Inspiration
This project is inspired by a number of great projects:
- OpenBSD and UNIX in general for most of the concepts
- Plan9 for the great abstractions and simplicity
- suckless and cat-v for minimalism