Dear Wiki user, You have subscribed to a wiki page or wiki category on "Qpid Wiki" for change notification.
The following page has been changed by kpvdr: http://wiki.apache.org/qpid/AMQPVersion ------------------------------------------------------------------------------ === DISADVANTAGES: === a. There is no easy way of hosting more than one version of AMQP at the same time in the broker. a. The code that touches the version-specific generated method body classes is scattered all over the place. This makes it difficult to maintain the code if there '''''is''''' a change to the AMQP protocol. In order to help conceive the scope of possible protocol changes (outside of any policy the AMQP WG may have in this regard) consider the following possible change types/scopes: - 1. A method call (class, method, fields, types) do not change, but the use or purpose of a field changes; + 1. A method call (class, method, fields, types) does not change, but the use or purpose of a field changes; 1. A method call changes the type of one or more fields; 1. A method call changes the number of fields (including by removing a field from one version to the next); 1. A method call changes the order of the fields; @@ -132, +132 @@ a. Complexity... a. This generation is beyond the capabilities of XSLT (or would be inordinately difficult), and we would need to switch to either Python (or Jython) or a purpose-written Java generator to do the job. a. It is not clear from the interface what field is valid in what version. There has been some discussion on name-mangling to solve this, but the general dislike for name-mangling in general and the complexities it brings seem to outweigh any advantages... - a. A couple of other things I have not seen yet!
