On 7/26/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
I think that where possible the 0.10 client should behave as the 0.8client does, by default certainly, unless we can think of a very good reason for the departure.
[RA] Fair enough. However the only assumption that existing clients should make is that the new client will be JMS compliant. In our documentation we haven't promised anything else. And it is also not wise to expect anything more as we have a very fluid spec that is still in the process of being finalized. Things like failover etc may changes as the AMQP spec changes. Reason: code has already been written to the 0.8 client, it
would be a pity to have to rewrite it to a different set of assumptions for 0.10. Certainly not unless there is some compelling advantage in doing so.
[RA] I would assume that code is written assuming the JMS API ?? Anything more is a clear mistake, unless written with the explicit understanding that it may have to be rewritten btw versions. We have API's for that precise reason. Anything under the hood can be changed. Anything non standard is not guaranteed to be supported btw versions. One reason why we want a Qpid API is for people to use AMQP specific features in a standard way. This API must be honored btw versions. Using switches like strict AMQP is a clever hack, but clearly a short term stratergy. The Qpid API should be the long term strategy. Any comments? I'm sorry, but I just can't help but feel that you want to change things for
no better reason than that you 'feel' it would be a preferable solution. What we have at the moment is practical and it works, and I don't think I would go so far as to describe the learning curve as steep. By all means add new functionality (such as a nice tool), but please think very carefully before you break old stuff. The 0.10 client should dynamically create destinations in the same way that 0.8 does, by default. Rupert On 26/07/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-07-26 at 12:58 +0100, Martin Ritchie wrote: > > Is adding option=value to the end of a url really more complex than > > putting it on a new line? > > > > I would say that you would require more information in the new line > > approach so that you can associate that option to the specific > > connnectionfactory defined in the file. > > You may be right, I was thinking about simplifying the URL scheme based > on feedback I had from non-expert people trying to write a "hello word" > JMS application. > Would it be acceptable for you if we keep the existing scheme but also > accept URL of type: amqptcp://host:port/virtual_broker that uses all the > default properties i.e.: tcp, guest, guest with a single broker. The > name "amqptcp" is bad, I am sure we'll find a better name. > So we would have the advance URL for advance users and a simple scheme > for beginners that we can use to write samples. What do you think about > that? > > > I don't think I'm seeing failover differently but I think we are > > seeing the JNDI properties file differently. I see one file with a > > number of connectionfactories defined that can be used to connect to a > > number of different clusters. Hence that connection factory needs to > > know all the broker details associated with that connection/cluster. > > From what you are saying would I be correct in thinking that you see > > the JNDI properties file with at most a single cluster defined. > > You are right, I was seeing a one to one mapping between a cluster and a > JNDI property file. > > > I agree that having a tool to create queues/topics/destinations on the > > broker would be helpful as that is what people expect when migrating > > from other messaging products. The current automatic declaration is a > > convenience for JMS users. > > Great, it should be simple enough to provide such a tool by using the > new JAVA Qpid APi. > > > However that said looking up a JNDI object doesn't cause any creation > > on the broker. I did h ave a patch to commit to add a System Property > > which would stop the client performing exchange/queue declare for each > > new consumer. So if the queues didn't exist they would get an error. > > It appears I forgot to commit it :) (more likely hadn't fully tested > > it) > > > > When we have full ACLs on the broker then would have no need for this > > as the client would have to have permission to declare > > queues/exchanges. So some sort of tool will be required at that stage. > > So, should we say that the 0.10 client does not dynamically create > destinations (apart form temporary ones obviously) or that it tries of > declaring destination that are defined in the JNDI properties file? I > think that both approaches would be acceptable. > > Thanks > > Arnaud > > > >
