Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: clarification.

 

Client Protocol 

Client The new client/server protocol should be simple enough to implement in any programming language.

Streaming/ Continuous Response

The Protocol should be able to send The protocol should support the server sending a partial or chunked response to the client . It should have the ability in order to reduce the need for large buffers. This allows users to implement the Observer pattern so that one party is notified of a state change in the other.

Framing

If an Object is large then client/server should be able to send that object in chunks.

Pluggable

Server The server-side implementation should be pluggable. In particular, we should be able to optimize both the encoding and the network stack for speed and garbage creation.

JSON Support

Server The server should be able to interpret JSON document documents in a client api requestrequest, and then convert that to pdx using JSONFormatter, vice PDX using the REST-API's JSONFormatter and vice-versa.

Region Key as byte[]

We should be able to support byte[] as a region key.  This involves storage components and is primarily a goal in order to reduce cache overhead.

Performance

It should be performative similar to current Geode clientThe new protocol implementation should have similar performance to the current protocol. That is, applications shouldn't take a performance hit if they switch from the old client APIs to those based on the new protocol.

Versioning

Should we need to add features or functionality to the client, it should be easy to add create a new version of the protocol, and allows both allow multiple versions to operate with different clients on a single server.

Authentication/Security

It must be possible to transmit the protocol over TLS. We will also use support Diffie-Hellman key exchange; this should be supported (however, this is mostly just means a matter of exchanging some bytes).