qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: The future of Qpid Management.
Date Tue, 25 Feb 2014 22:35:50 GMT
I think the QMF and the tools around it demonstrate the problem of tools
modeled only according to some schema. Utilities like qpid-tool allow you
to find the schema details about the objects/classes and their methods and
call these methods. But if you want to use the filter in the purge method
of a queue object, it doesn't really tell you how should the filter
attribute look like.

It is of course great to be able to save development effort and to have at
least some tools. But the value of such tools to the end user is often
questionable, especially since it is often connected with missing
documentation. Unfortunately, external repository on amqp.org doesn't
really resolve such problem.


On Tue, Feb 25, 2014 at 8:38 PM, Fraser Adams <fraser.adams@blueyonder.co.uk
> wrote:

> On 25/02/14 10:28, Gordon Sim wrote:
>> [...]
>>> Similarly neither QMF nor AMQP 1.0 Management
>>> provide a way to introspect Method formal parameters. So you can get
>>> hold of the available Method names for sure, but arguments/parameters??
>> I think you can get this over QMF. For example, using qpid-tool you can
>> type: schema queue, and that gives you all the methods as well as their
>> parameters including types and a basic description.
>>  I *thought* that schema information was only available from QMFv1 (where
> it was necessary because QMF1 wasn't "self describing"). TBH it has been a
> while since I looked, but back in the day when I was testing my Java QMF2
> stuff the C++ broker didn't return useful things for most of the schema
> query methods. It *might* have been updated since then, but I sort of doubt
> it (because schema stuff is generally not needed in QMF2) I actually put
> together a patch along with a Jira *ages* ago (I think it was ~0.12
> timeframe) that took the QMF1 schema stuff and mapped it into QMF2 Map
> Messages, but nobody seemed especially interested (again I guess because
> the schema stuff isn't essential for QMF2) so I didn't particularly pursue
> it. I've attached the patch for interest though clearly things have moved
> on a bit since then.
> It's certainly not available from AMQP 1.0 Management though :-/
> Schema stuff is one of those interesting things that you kind of don't
> miss until you miss it :-) I think that QMF1 was a bit of a pain because
> you needed to have it, so I quite like that you can live without it with
> QMF2 and AMQP 1.0 Management, but OTOH if you want to put together any
> platform agnostic tooling it turns out to be kind of handy :-)
> That said, I've got no great love of the mechanism QMF2 adopted for schema
> retrieval, I guess it allows one to retrieve a bit at a time, but I'm not
> clear why you'd want to do that, if you actually care about schema you'd
> *probably* want the whole thing in which case you wind up with a whole
> bunch of network calls. In this day and age I'd personally opt for a simple
> call that can return a Container's Management Schema as a JSON object (or
> perhaps an AMQP Map might be more appropriate).
> Rob I'd be interested in your thoughts, the AMQP 1.0 Management
> Specification certainly allows partial schema information given GET-TYPES,
> GET-ATTRIBUTES and GET-OPERATIONS and I think if the latter two are
> specified without an entityType they will return all attributes and methods
> (the returned map has entityType as a key) but GET-OPERATIONS only returns
> the method names, there's nothing that describes arguments, which is I
> think a limitation.
> As I say my gut feeling is that returning the entire schema in something
> JSON like is:
> a) Likely to be the most useful thing to do from the perspective of users
> of the Management system
> b) Is likely to be the easiest thing to implement - as it stands you end
> up with some slightly fiddly code and you almost certainly have to encode
> your schema information in some slightly unnatural way, whereas it's likely
> to be pretty simple to create say a JSON document (or even string in the
> code) to describe the Management Schema and either simply return the JSON
> or encode it as AMQP Map/List etc. (and both the C++ and Java brokers
> already have code to do that 'cause that's pretty much what the Address
> Parser does).
> I'm interested to understand the logic behind the current thinking 'cause
> the more I think about it the more I think it's not as useful as it could
> be.
> Frase
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message