On 25 February 2014 23:35, Jakub Scholz <[email protected]> wrote: > 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. > > Agreed... I don't think auto discovery of meta data really makes for good tooling. The idea of the registry is more to allow implementations to agree on an aspect of behaviour (let's say purging a queue with filters) and write up how that would work, and publish it as a "type" that a queue implementation could provide. Having done that, if a tool vendor has put in the work to understand that type, it would recognise its presence on a queue implementation written for an AMQP 1.0 implementation that the tool writer had known nothing about.
So, Qpid could define its queue as being of type org.apache.qpid.SuperQueue which implement org.apache.qpid.Purgable (where externally we have written up the semantics for org.apache.qpid.Purgable)... Another vendor could come along and write their queue in their broker, and also support a purge operation... so their com.foo.BestEverQueue will also implement org.apache.qpid.Purgable. A tool written to work with the aspects it knows about will be able to deal with this queue supporting the standard operations, operations defined in org.amqp.Queue and also the operations defined in org.apache.qpid.Purgable ... obviously the tool would not be able to support the other operations that might be available on com.foo.BestEverQueue... but then the end users can petition the tool writer to recognise those features too. -- Rob > Regards > Jakub > > > On Tue, Feb 25, 2014 at 8:38 PM, Fraser Adams < > [email protected] > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > >
