These are chat archives for atomix/atomix
Copycat 2.0 and Atomix 2.0 are currently under development. I'd like to invite anyone with ideas on what they'd like to see in the projects to contribute to the discussion.
The development that is currently underway focuses on usability, portability, and performance:
I'm open to other ideas from users.
Good question @ccleve
So, we're certainly not going to add any additional overhead to Copycat/Atomix. I'm only interested in the JAX-RS annotations insofar as they're a widely used, well documented, well understood API. Ultimately, using JAX-RS annotations is just a nice way to specify a REST API for a state machine. In practice, the state machine isn't actually itself a REST server since Copycat has to handle and replicate changes before they're applied.
So, really how it's structured is: the Copycat server can be configured with an
HttpProtocol. When the
HttpProtocol is used, a basic Netty HTTP API is set up for managing sessions and things like that. All requests that don't relate to session management are intercepted by the HTTP and converted into HTTP commands and queries (
GET requests and
HttpCommand for everything else). From that point, the HTTP operations are handled like normal operations, logged and replicated if necessary. Once they're committed and applied to the state machine,
HttpQuery are specially handled in the state machine using the JAX-RS annotations. So, really this is just a nice way to specify an HTTP API for a Copycat state machine without actually using any of the existing implementations of the JAX-RS spec. Copycat is essentially it's own implementation of the spec.
I'm still not sure I'm sold on using JAX-RS annotations though. The alternative is a code-based configuration of an API or implementing some annotations specific to Copycat's HTTP support. I think the final direction will depend on how clean this approach feels when I get to it this weekend. Handling HTTP requests in the state machine will be the last major phase of refactoring.