Skip to content
json-amp edited this page Mar 22, 2012 · 5 revisions

JAMP Home, Wiki Home, Visual tutorial, Language Mappings, Marshaling, and Routing, WebSocket Intro, WebSocket versus Ajax and REST

The reference implementation (RI) so far is in Java. The RI will include Java, Python and JavaScript. The RI will focus on communication of ideas and a working model. It will not focus on speed. Hopefully others will fork it and come up with faster versions.

The code for Java and Python will be written in very plain and simple code. There is no fancy tricks and no complex design patterns or frameworks (no Spring, no CDI). (Hopefully there will be CDI, GUICE and Spring extensions, but not in the base framework.) The emphasis is on simplicity like JSON itself. No foreign frameworks or complex dependencies. You should be able to drop in a jamp jar file and it just works.

Given the option of a five case if statement or a command pattern, JAMP is going to use the if statement. (Readability is paramount.) There are no private variables. They are all package protected. This is done for readability and to make it easier to convert to other languages.

The plan is to first write a Java version (REST/WebSocket/STOMP), and a JavaScript client (REST/WebSocket).

The plan is to convert the Java version into Python.

Then convert the Java version into ObjectiveC, C#, Go, C++, and Dart. These conversions will be more or less transliterations from Java to these languages.

Then convert the Python version into PHP, Perl, and Ruby. These conversions will be more or less transliterations from Python to these languages.

The hope is after a few conversions, that others will join the fray.

Keeping JAMP simple yet working on many, many platforms is the goal. Complexity is death. If it can't be explained easily then it must be dropped from the RI. Therefore, bindings, marshaling, and routing follow simple rules that are easy to implement.

There should be nothing in JAMP that is overly complex. If I can't explain it easily, then it should not exist.

It is a simple layer that works over WebSocket, STOMP, REST/HTTP and AMQP. It is hoped that there will be extensions, but that they will be ported to other languages if they are common.

I would like JAMP if possible to have its own client libs for STOMP, WebSocket and AMQP. This way for example you could drop JAMP into a Java Servlet and it can connect to others.

This may not be feasible and if not JAMP will look for the most common, most standard client libs for STOMP, WebSocket and AMQP.

Once five or so languages have bindings and JAMP has some momentum. Then there will be a binary protocol for JAMP similar to BSON, Hessian or Google protocol buffers (Most likely Hessian 2.0ish).

This should allow JAMP to be used for streaming.

Java coding stye to support easy translation to other languages (applies to org.jamp and org.jamp.impl):

  1. No Exception other than java.lang.Exception in JAMP API
  2. No method overloading. If two methods do same type of thing but take different args, then there will be different method names.
  3. No private variables. I will only use package variables.
  4. No comments, there will be a WIKI page that describes all classes in a tutorial format so it will be easy to port.
  5. No Dependency Injection or anything really fancy. Just a factory and interfaces
  6. Limited extensibility (it is a RI for a simple protocol whose value increases with portability not extensibility)
Clone this wiki locally