From users-return-7921-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Thu Mar 21 18:18:50 2013 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0B9A6F47D for ; Thu, 21 Mar 2013 18:18:50 +0000 (UTC) Received: (qmail 18197 invoked by uid 500); 21 Mar 2013 18:18:49 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 18143 invoked by uid 500); 21 Mar 2013 18:18:49 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 18135 invoked by uid 99); 21 Mar 2013 18:18:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Mar 2013 18:18:49 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fraser.adams@blueyonder.co.uk designates 81.103.221.52 as permitted sender) Received: from [81.103.221.52] (HELO mtaout04-winn.ispmail.ntl.com) (81.103.221.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Mar 2013 18:18:41 +0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.3]) by mtaout04-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130321181820.KUTX8801.mtaout04-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Thu, 21 Mar 2013 18:18:20 +0000 Received: from [82.38.114.236] (helo=[192.168.1.103]) by know-smtpout-1.server.virginmedia.net with esmtpa (Exim 4.63) (envelope-from ) id 1UIk2i-0000GW-6V for users@qpid.apache.org; Thu, 21 Mar 2013 18:16:48 +0000 Message-ID: <514B4E8F.1090504@blueyonder.co.uk> Date: Thu, 21 Mar 2013 18:16:47 +0000 From: Fraser Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release References: <403354247.17445814.1363871974412.JavaMail.root@redhat.com> In-Reply-To: <403354247.17445814.1363871974412.JavaMail.root@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA= c=1 sm=0 a=ha7hkxcCzSMA:10 a=cC4U6xD4W74A:10 a=3NElcqgl2aoA:10 a=IkcTkHD0fZMA:10 a=3q265_XjX2v3NDIBHZUA:9 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Virus-Checked: Checked by ClamAV on apache.org On 21/03/13 13:19, Ken Giusti wrote: > I'd rather see a single "top level" broker configuration command that supports all the configuration aspects of the broker. Openssl and NSS (certutil) take this approach. I think it would tend towards unifying the configuration experience (e.g. naming of common options would be consistent, need for familiarity with only one command, etc). > Ooohhh now you're talking!! So I'll take it a stage further I'd like *very much* to see a unified approach that aligns configuration not just limited to "all the configuration aspects of the broker" but unified configuration and monitoring across the C++ and Java brokers (and beyond, wouldn't it be just grand to set a good precedent for unified AMQP management?). I've made a bit of a start on this grand crazy vision, you might have seen my post at the weekend announcing a QmfManagementPlugin for the Java Broker. It might not be the "right" approach I'm taking, but hey I've got qpid-config and the QMF GUI both working with both brokers, which seems like a pretty decent start. The main limiting factor isn't so much "the control protocol" be it QMF/JMX/REST/whatever there remain some differences in the underlying management models which ought to be addressed - it's very frustrating when even for arguments with the same of very similar purposes the option name may be different between the brokers. Never mind just config aspects I'd quite like an AddressString that I had working on a client talking to the C++ broker to behave the same way when I talk to the Java broker. I'm probably already sounding like a broken record on this topic, is it just me or do others share this crazy vision? If not is there a really compelling reason for the brokers behaving so differently? Cheers, Frase --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org