qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: The future of Qpid Management.
Date Tue, 25 Feb 2014 19:38:21 GMT
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.


View raw message