package mimic

  1. Overview
  2. Docs
A simple protocol dispatcher

Install

Dune Dependency

Authors

Maintainers

Sources

mimic-0.0.3.tbz
sha256=e4743cd2e4f8242eb1ce9d8086fd2affba0eb6a62131309ffa279108bd3dbbcb
sha512=8c3c0508c09af4694f16738039965f36909952a694a8203356aa002810c9cec589510544f053377e9e43fa902c59d8cd00aa02dda57e8cdba02ee0e20b4f2bbb

Description

A middleware to dispatch protocols

Published: 20 Apr 2021

README

Mimic, a full-abstract way to instantiate a transmission protocol

mimic is a small project which gives you the opportunity to instantiate a transmission protocol - such as a TCP/IP connection - from dynamic values. A simple tutorial is available here. It explains to implement a ping-pong protocol and upgrade it to TLS.

Some examples

git or paf are examples where they use mimic as the only transmission protocol implementation available. It permits to be compatible with MirageOS without the complexity of functors (commonly used with functoria to unlock the possibility to abstract anything).

Design

mimic is pretty-small (~ 700 lines) and the API wants to fit into several different contexts (HTTP, TLS or SSH). It's possible to make helpers from it such as some derivations for unix or mirage - as we commonly designed for [conduit][conduit]. However, with a big retro-spective, such piece of code should not include these derivations.

Indeed, they give an opportunity to the user to assert a non-compaibility with MirageOS if you use the unix derivation for example.

mimic wants to be abstract and "simple". Then, the user is able to construct something more complex and easy to use at his level - and it's what paf does for example or git-unix.

Reverse dependencies

mimic must be thought according to who use it. The API is not designed to be canonic and usable as is. It has been thought to unlock the full abstraction and the compatibility with MirageOS for others projects.

If you think that you can have an usage of mimic and something is missing, you should implement what you want outside mimic.

The Mirage_flow.S interface

Finally, the only assumption about design of protocols, transmission protocols, etc. is Mirage_flow.S. Several issues exist about this interface but the cost to upgrade the interface (to be unix-friendly for example) is huge when several MirageOS projects trust on this specific interface.

Documentation

mimic can be hard to explain when we don't know all details about the MirageOS eco-system. The existence of this project can be critized when we don't really understand all details and how this project fits in.

The documentation is not very clear and does not explain the big-picture of mimic. So it's a real issue and the tutorial wants to fix it but my lack of English does not help me.

Dependencies (8)

  1. logs >= "0.7.0"
  2. rresult >= "0.6.0"
  3. result >= "1.5"
  4. mirage-flow >= "2.0.1" & < "4.0.0"
  5. lwt >= "5.3.0"
  6. fmt >= "0.8.9"
  7. dune >= "2.8"
  8. ocaml >= "4.08.0" & < "5.0"

Dev Dependencies (6)

  1. ke >= "0.4" & with-test
  2. cstruct >= "6.0.0" & < "6.1.0" & with-test
  3. bigarray-compat with-test
  4. bigstringaf >= "0.7.0" & with-test
  5. alcotest-lwt >= "1.2.3" & with-test
  6. alcotest >= "1.2.3" & with-test

Used by (8)

  1. git >= "3.0.0" & < "3.7.0"
  2. git-cohttp-mirage
  3. git-mirage >= "3.0.0"
  4. git-paf < "3.7.0"
  5. git-unix >= "3.4.0"
  6. irmin-git >= "3.1.0"
  7. paf < "0.0.9"
  8. spoke

Conflicts

None