Stomp Future

While thinking about the future of Stomp protocol, we concluded that the best place for future maintenance of the specification is under umbrella of ActiveMQ project. There are a couple reasons for this, but it basically boils down to two facts:

  • Apache infrastructure is much better suited for this task than the one currently used at Codehaus
  • Most of the Stomp contributors are also ActiveMQ committers, so this transition feels natural in this respect.

As a starting point, we created an ActiveMQ sub-project http://activemq.apache.org/stomp/ which will be the home of the all future work on the protocol. At the moment, we only ported information related to Stomp version 1.0 (specification and related articles) to this new project. Soon, we’ll start working on protocol specification version 1.1, using the current idea pool as a base.

The whole documentation for the project is created using Webgen, so it consists of Markdown pages stored in an appropriate SVN repository (for example, Stomp 1.0 specification is located in here). You can also use Jira to file any tasks, issues and requests for the specification related work. So please feel free to contribute 🙂

This project is not meant to contain any Stomp clients, but only to be a home of the Stomp specification. This doesn’t mean that we don’t think about how to provide the better infrastructure to Stomp clients developers. But that is the topic for another discussion and you can expect more news regarding that soon.

7 comments

  1. This change looks like it is making STOMP more ActiveMQ specific. The JMS mapping information has moved to top level of AMQ documentation and is no longer included with the “specification” as such. It would be a shame to see the specification tightly bind to the AMQ implementation as there is some of us who are sing it to talk to other servers 🙂

    Looking at http://activemq.apache.org/stomp.html the following sections seem relevant for at least the OpenMQ implementation of STOMP

    • “Working with Destinations with Stomp”
    • “Persistence of Stomp messages”
    • “Working with JMS Text/Bytes Messages and Stomp”
    • “Stomp extensions for JMS message semantics”

    Also it may be useful to link to the OpenMQ stomp implementation docs for the extra clarifications and enhancements that their implementation requires.

    https://mq.dev.java.net/4.4-content/stomp-funcspec.html

  2. Hi Peter,

    this move doesn’t intend to do anything like that.

    There’re two different things I think you confusing. The first one is the Stomp specification, which is located at http://activemq.apache.org/stomp/ and it is literally the same as the one hosted at Codehaus.

    The other is Stomp implementation done in ActiveMQ. Those information are located at the http://activemq.apache.org/stomp.html (different url).

    These two things are quite separate and all jms related stuff is ActiveMQ specific and not part of the specification. As I said, the only intention is to provide a better place for the future maintenance of Stomp protocol, which will by all means be open.

    Cheers

  3. No I understand that this is how you are documenting it now. Previously you documented StompJMS as independent of ActiveMQ and the documentation at Codehaus is still up at http://stomp.codehaus.org/StompJMS while you may have intended this as ActiveMQ specific (or more likely specific to StompConnect) it was at least seen as common. As such the OpenMQ people went ahead an implemented it. I am not sure if any other vendors have done so. OpenMQ people also implemented some other ActiveMQ specific stuff (prefixes for different destination types).

    I guess even if this is not intended as part of the standard it should at least be documented as a common implementation choice. Especially as most of it is not really specific to a particular MQ product but instead to JMS style interfaces. If not for 1.0 maybe for 1.1

  4. Hi Peter,

    thanks for pointing this out. Stomp JMS stuff is not in the 1.0 spec, but definitely should be among “additional resources”. I missed adding it in the first pass purely by accident. I’ll add it as soon as possible.

    Just to repeat again, nothing changes to the Stomp 1.0 spec (and all resources related to it). This move will just make it easier to work on Stomp 1.1 (which will be broker agnostic as 1.0 was).

    The new site is also just set, so more material will be added in the process.

    Thanks for your comments.

  6. Pingback: night tale » Fuse Stomp project

Comments are closed.