github.com/gdamore/mangos@v1.4.0/PLANS.md (about)

     1  
     2  PLANS
     3  =====
     4  
     5  mangos has been quite successful, but over the past several years we've
     6  worked on NNG and nanomsg, as well as mangos, and it's time to consider
     7  some major future work in mangos.  This document describes those plans
     8  in order that everyone who uses mangos can be aware of these.
     9  
    10  Note that mangos is developed with Semantic Versioning in mind, so the
    11  changes described here are plans for the next major version (2.0) of mangos.
    12  Users of mangos 1.x can continue to use mangos 1.x for the foreseeable future.
    13  
    14  Harmonization with NNG
    15  ----------------------
    16  
    17  (See github.com/nanomsg/nng to learn more about NNG.)
    18  
    19  Mangos has some features (notably the STAR pattern) that NNG lacks, where
    20  NNG has others that mangos lacks (PAIRv1 protocol, contexts, ZeroTier
    21  transport.)  Over time we would like mangos to "acquire" all of the features
    22  that NNG has, and vice versa.  The context support in particular is a huge
    23  boon for folks writing concurrent applications, and as an innovation
    24  We're sorry we didn't think of it during mangos' development.
    25  
    26  In addition, some of mangos' terms for concepts are unfortunately different
    27  than those used in nanomsg and NNG.  Much of this stems from our imperfect
    28  understanding of nanomsg architecture when we first wrote mangos.
    29  
    30  Finally, mangos suffers in some architectural ways because it is "too simple".
    31  That is to say, we have some patterns that would be better and more efficient
    32  if we could change them to have more knowledge of underlying endpoints, and
    33  give them more visibility into outstanding requests.
    34  
    35  Performance
    36  -----------
    37  
    38  Mangos is built on top of channels, and uses them heavily, as that was
    39  seen as the most idiomatic way to do things.  Unfortunately, we've seen
    40  demonstrated quite well that Go's channels are pretty poor for certain
    41  use cases, from a performance perspective.  Adding new cases to select
    42  statements, for example, can have a quite measurable impact on performance.
    43  
    44  A better, more complex, approach would be to use condition variables and
    45  mutexes a bit more intelligently.  This may be more error prone, and
    46  not something novice developers should do, but we've ample experience with
    47  these constructs from our C and kernel background.  We've long wanted to
    48  fix these in mangos.
    49  
    50  Nanomsg Affiliation
    51  -------------------
    52  
    53  When we started mangos, mangos was an "outsider" to the nanomsg organization.
    54  We intentionally wanted to avoid creating any false impressions of being
    55  officially blessed by the nanomsg team.  Of course, times have changed,
    56  and we've taken over the nanomsg project.  It's time to bring mangos into
    57  the nanomsg umbrella.  In mangos 2.0, the import path will be moving from
    58  go-mangos (a separate dedicated organization) to nanomsg.org.  Mangos
    59  is *the* officially recommended Scalability Protocols implementation for
    60  Golang applications.  Most likely the import path will become just
    61  nanomsg.org/mangos or possibly nanomsg.org/go-mangos. (We anticipate that
    62  the actual code will continue to be hosted on GitHub, but in light of
    63  recent news about the Microsoft acquisition, it seems like a good time
    64  to stop hard coding GitHub in our package import paths -- the freedom
    65  to depart if things go south at GitHub seems a worthwhile goal.)
    66  
    67  Abandoning Compat Package
    68  -------------------------
    69  
    70  The compat package was built to make transitioning from op/go-nanomsg
    71  as easy as possible.  (That package is just a native binding to the C
    72  library, and hasn't received any updates in about 2 years.  We think nobody
    73  is really using it anymore.)  We intend to remove the compat package
    74  from mangos as part of the mangos 2.0 effort.
    75  
    76  Modern Golang
    77  -------------
    78  
    79  There are some compelling reasons to begin requiring Golang 1.8 or newer,
    80  and mangos 2.0 will require it.  For example, net.Buffers will allow us
    81  to make some changes that should substantially improve latency for TCP
    82  based transports.  The WebSocket transport can begin to use the native
    83  WebSocket API in golang now that https://github.com/golang/go/issues/5082
    84  is fixed.  We might begin looking at the native context support that
    85  is present in modern Golang as well.
    86  
    87  New Transports
    88  --------------
    89  
    90  We expect to bring in transports with support support for QUIC, possibly KCP,
    91  raw UDP, and are contemplating an SSH based transport.  ZMTP is a distinct
    92  possibility in the future as well, as that might lead us to a CurveMQ
    93  transport.  (We have no ill will towards ZeroMQ, we just don't like C++ and
    94  the GPL.)  Folks have expressed an interest in RDMA style protocols as well,
    95  though we would need to have commercial investment to make that happen.
    96  
    97  New Protocols
    98  -------------
    99  
   100  We have design work for a sender-filtered PUB/SUB protocol, as well as
   101  true multicast delivery, which turns out to be non-obvious in the face
   102  of devices, etc.
   103  
   104  There are a number of other patterns which have been discussed, and we
   105  would like to explore these.  Further, some of the existing protocols
   106  can benefit from further hardening against device loops.
   107  
   108  Usability Enhancements
   109  ----------------------
   110  
   111  We think mangos is pretty easy to use, but there are some things that can be
   112  improved upon.  Context support is a big one here, but there are a small
   113  assortment of other ones -- such as easier access to remote pipe credentials
   114  and a better hook mechanism for remote peer connections.
   115  
   116  Observability
   117  -------------
   118  
   119  It's long been our desire to add deep observability into mangos, starting
   120  first and foremost with rich statistics.  We'd like this to be a key
   121  deliverable for a 2.0 release.
   122  
   123  Better Documentation
   124  --------------------
   125  
   126  The current documentation is fairly standard for Golang, but we really
   127  want more of a HOWTO guide to building distributed applications with mangos
   128  (and NNG).  A book is planned.
   129  
   130  Call for Sponsors
   131  =================
   132  
   133  NNG has been fortunate to have received excellent commercial sponsorship,
   134  much of which informs the list of things we want to do here.  However,
   135  in spite of having broader use, mangos has obtained only a small fraction
   136  of the commercial sponsorship that NNG has.  The single best way to help
   137  accelerate any of the above work items is to sponsor their development.
   138  Please contact Staysail Systems, Inc. (info@staysail.tech) to inquire
   139  about sponsoring any of the above items.