This repository contains an attempt of creating a docker client library in GNU Guile.

Zelphir Kaltstahl 16df9f042e add mapping macro for HTTP method to simplify define-api-route 3 jaren geleden
guix-env 6d9c75579f add guix environment 3 jaren geleden
LICENSE e5e252c214 Add LICENSE 5 jaren geleden
README.org a49b3bd0cf initial commit 5 jaren geleden
api-utils.scm 16df9f042e add mapping macro for HTTP method to simplify define-api-route 3 jaren geleden
container.scm cdc5bc31af change imports to other syntax 3 jaren geleden
docker-socket.scm 5981602c89 close socket after usage 3 jaren geleden
docker.scm d55fc9ac47 restructure 3 jaren geleden
list-helpers.scm cdc5bc31af change imports to other syntax 3 jaren geleden
model.scm cdc5bc31af change imports to other syntax 3 jaren geleden
url-helpers.scm cdc5bc31af change imports to other syntax 3 jaren geleden

README.org

To do [0/5] [0%]

  • [ ] data abstraction layer for things like the structure of a filters argument for GET
  • ~/containers/json~.

If guile-json changes its Scheme representation of JSON values, we should be able to translate this docker API client by only changing things in one place, instead of having to change everything. The idea goes as follows:

  • We need some in-between object, which we define ourselves.
  • The in-between object can store arbitrary data, which is translated back to url-encoded
  • (percent-encoded) JSON strings for use cases of the docker UNIX socket API.
  • This in-between object is used everywhere in the library, instead of building the expected
  • structure for ~guile-json~ everywhere.
  • We write code to get the current guile-json Scheme JSON representation from the in-between
  • object.
  • The in-between object should be very easy to create.
  • For now the in-between object can be just the representation the guile-json library makes use
  • of. It only needs to be passed through a constructor and a transforming procedure, which both do no transformation, as there is no change in ~guile-json~ yet.
  • [ ] Implement more routes to witness more (edge) cases to be able to choose good abstractions.
  • [ ] Document the idea of having multiple levels of docker API calls (all routes, combination of
  • routes, and higher level calls, which are arbitrary combinations of combinations of calls).
  • [ ] Implement checks for arguments according to a defined docker UNIX socket API version.
  • [ ] Define which docker UNIX socket API version the library is written to work with and pay
  • attention to making it work with that version.