[RFE] Messaging system design

[rarebreed]

Rationale

The messaging system is relatively complex and should be thought out better. In particular, need to flesh out:

• the messaging data format
• the protocol between client and services
• abstracting the transport mechanism
• how the adapter will bridge the different application protocols (eg http-rest vs uplift-tls-binary)

  Benefit

It's not un-agile to design something before coding away. By having these ideas documented, it will be easier to implement and test.

Concerns

A lot can go wrong here. Why not use netty for example instead of writing our own TLS NIO.2 SocketChannel implementation? For starters, netty is not trivial in and of itself and the documentation is somewhat sparse (they do have some half-way decent examples though). Also, since it uses Java under the hood, it doesn't give us immutable data structures or the ability to use core.async or STM as needed. That being said, netty is still a possibility.

Furthermore, netty doesn't do much to actually help you write your own protocol and data exchange format. Right now, there are a lot of contenders for binary data exchange formats: google protocol buffers, thrift, fressian, transit and others.

[rarebreed]

The code can now send messages from the client to the server reasonably well. Currently, the client is using a CharBuffer to send messages to the server, and the server simply echoes the message back.

However, I think this is on the right track. Work needs to be done on:

1. Figuring out a way to stop a client and the server
2. Change the buffer type to a UpliftBuffer (which extends a ByteBuffer and implements a UBuffer protocol
3. Routing messages from one client to another
   • Right now it's client talking to server, but the server should just be a hub or router