On 05/06/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
There is also some demand for a very low level protocol level client that works at AMQP method level from other projects who want fast AMQP support w/o bothering to use any JMS. There is also a demand for a slightly higher level java client w/o any JMS.
Where is this demand and what is the reason for it? Is this because a low level API must be in some way faster, or that Real Men program at the lowest level and JMS is for quiche eaters? I have said this many times now so I promise this will be the last, but I think having two end user APIs is a mistake. What do you say to users who use JMS and want to take advantage of some specific AMQP feature? Rewrite your application to use our "other" API?
While most end users prefer JMS, most infrastructure projects wants native support and likes a framework like client to work with.
Why is this?
Adding more methods to JMS is IMHO not the correct way to expose AMQP features, neither does it do any justice for the AMQP features.
Why not? Can you give a concrete example?
If we are trapped in the JMS mentality for long we will not evolve. It's wise to have support for JMS. However it's prudent to be a bit more radical and have an AMQP client. It certainly has enough merit to deserve it's own.
I don't understand this argument. You accept the need for a JMS client but you seem to think that we are then doing our Java users a favour by making that some third rate distant cousin that we send a Christmas card to every year but otherwise shun? I have argued strongly in the past (before Qpid was open sourced) against having an API that too closely mirrored the protocol, because of the likelihood of protocol changes and the impact that would have on existing users. Imagine we had a wire level API (oh we could have called it WireAPI to pluck a name from the ether) that people were coding to. How would we deal with the kind of changes planned for the protocol? We would be faced with either having a lot of work to maintain the API and map it to the new protocol or tell our users "sorry you're just going to have to rewrite your apps".
[RA] No the existing message factories are too tightly coupled with JMS. I am proposing three generic message factories. TextMessageFactory, XMLMessageFactory, BytesMessageFactory. (We can add more in the future .. example SOAPMessageFactory).
In what way are they coupled to JMS? I had envisaged there being a method with signature: Message createMessage(String mimeType) on Session that would allow the creation of arbitrary message types (that had been registered).
[RA] The intent is to replace the existing client. Please read my general comment about the rational behind it. Several of us tried to re-factor the existing client with limited success. Hence we decided to rewrite the client.
I think it's a good time to revisit the client as we approach the 0-10 protocol. Having a proper logical separation of the client into an upper and a lower layer is important to help us keen sanity while the protocol evolves. There are other things we should be isolating ourselves from too, such as MINA so that we could plug in other network frameworks (e.g. Grizzly). I do however tend to agree with Joel Spolsky who argues far more eloquently than I can against complete rewriting in general: http://www.joelonsoftware.com/articles/fog0000000069.html.
Continuous innovation is the way forward. That's what people expect from open source projects as opposed to proprietary projects.
A product-focussed mindset is essential if we want to grow our userbase. People who want enterprise features such as more flexible authorization are not going to be impressed if you say "by the way, if you want to use these features you're going to have to spend $100k on code changes to your app".
[RA] One of the problems of the existing client is the indiscriminate use of the system properties with virtually no documentation. The code is littered with the use of system properties. One improvement I made is to unify the configuration using commons configuration. Now all configuration has been moved to an xml file which can be documented properly and configured easily. However u can continue to override these properties using system properties if u will.
This is an improvement to someone and another unwanted dependency to someone else. There was a deliberate decision not to use commons configuration. A client will be used in all sorts of situations, embedded in app servers etc. What if someone else wants to use another version of commons configuration that we don't support? We really need our own abstraction layer so that people who want to use different config mechanisms can do so (a bit like slf4j does for logging).
w.r.t amqp strict flag, what does this do? the java implementation is notorious for introducing non standard features. If u set this false does it mean we are doing something non standard ? why do we want to do that?
It was added to draw the user's attention to the fact that a particular feature used non-standard extensions to the AMQP protocol. As you may recall some JMS features could not be implemented with the existing AMQP protocol.
Frankly there was no API to start with, so there want be any incompatible API changes. Did we have an AMQP API visible before ?? (other than a few methods added as extensions to the JMS interfaces). I don't think u can call that an API.
Why not? I think it could have been extended but that is a different argument. RG
