[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [amqp] Groups - amqp-man-v1 0-wd11.doc uploaded
On Sun, 2015-05-31 at 22:17 +0200, Jakub.Scholz@deutsche-boerse.com wrote: > Hi, > > After the last TC call I finally managed to find some time to review > the > specs ... bellow are few questions / comments ... > > 1) What does it really mean when one entity type extends another > type? I > assume it means that it has to take over all attributes, operations > and > type annotations from the original entity type. Does this also > include the > possibility to treat the entity as the parent type (e.g. when I do > READ or > DELETE operations on a particular entity of type > com.example.priorityqueue > - can I do that by using type org.amqp.queue which it extends)? I > think we > should specify in the document what exactly extending means. My implementation does allow this. Frankly I think specifying a type on a request that has a unique entity identifier is redundant, so I don't object if there is no type (which is a minor spec violation but a major usability enhancement) If the type is specified I require that the entity identified by the ID be derived from that type. > 2) The second paragraph in chapter 2.4 states that "Each AMQP > container > MUST provide a Management Node with address $management". Since the > AMQP > clients (e.g. a JMS client) are also AMQP containers (or?) - do we > really > expect them to have the management node? Excellent point. Any *manageable* AMQP container MUST provide the address $management, but we should not imply that you cannot have AMQP containers that don't support management. > 3) Most requests (e.g. READ, UPDATE) contain the entity type and the > means > to identify a specific manageable entity (using identity or index > atribute). What error code should be returned when the manageable > entity > specified in the index exists, but has a different entity type than > specified in the request? (for example I request READ with > type=orq.amqp.queue with identity=user1 ... identity=user1 exists, > but it > has type org.amqp.user, not org.amqp.queue) Should this return HTTP > 404? As above: I think it is a usability problem to *require* the user to supply the type *as well as* a unique ID from which you can discover the type. I allow requests with no type. I can see the case for *allowing* the user to specify a type as "double entry bookkeeping". If the type is supplied I return 404 if the ID does not derive from it. > 4) Chapter 3.4, second paragraph refers to request's standard > application-properties name and identity as described in chapter 3.1. > But > the name and identity are not part of 3.1 anymore. They should be > removed. Oops. My bad. > 5) In the GET-ATTRIBUTES and GET-OPERATIONS operations, the > entityType > property limits the operation only to the specific type - i.e. it > does not > include the types which extend it. However, in GET-ANNOTATIONS the > types > extending the entityType are included in the results. Is that > intentional? > I would expect these three to behave in the same way. Is there some > particular reason why the should behave differently? I would make these consistently return all the attributes/operations/annotations whether defined by that type or by a base type. Most users ask about a type because they want to use an entity of that type. They need everything, direct or inherited. They shouldn't have to walk the class hierarchy to gather this information. There are use cases that care about the details of the hierarchy: schemas, meta-data browsers, doc generators etc. Those cases are less common and have to walk the hierarchy anyway so let them do the subtraction to figure out what is defined directly by each type. > 6) To be honest, I'm a bit confused by the annotations. They seem to > be a > bit "half baked" to me. Right now, they cannot be used for anything. > They > are basically just a label which can be applied to entity types, > nothing > else. What is the actual usecase behind them? To make them a bit > useful, it > would be nice to have them interchangeable with types - so that I can > for > example QUERY with entityType=com.example.stoppable and get all > entities > which implement com.example.stoppable annotation as a response. I use them but you are making me wonder if I should. My config file uses annotations as shorthand: e.g. write an "annotation" with common SSL configuration and reference it from multiple "connector" entity definitions. However the annotations are not part of the entity-type information model. My schema would be cleaner if I replaced them with "extends" inheritance. The shorthand feature could be separated as part of the config file implementation, not the general schema. I agree with re-evaluating annotations. An idea: drop annotations and allow multiple "extends". A uniform multiple-inheritance lattice with one node type and one link type would be easier to implement and understand than the present mixed lattice with two node types that are almost-but-not-quite the same and two link types, one single and one multiple. > > Thanks & Regards > Jakub > > > > From:> > Alan Conway <aconway@redhat.com> > To:> amqp@lists.oasis-open.org, > Date:> > 13/04/2015 16:45 > Subject:> > [amqp] Groups - amqp-man-v1 0-wd11.doc uploaded > Sent by:> > <amqp@lists.oasis-open.org> > > > > Submitter's message > Updated error codes as per last TC discussion. For operations using > identity or index lookup, using an unknown identity or index key value MUST > return Not Found. Using an invalid index attribute name MUST return Bad > Request. > > We talked about Not Implemented at the meeting but that is a server error > and using an invalid index is a client error so I used Bad Request > > I also added a general note that failure to include mandatory attributes > MUST result in Bad Request also. The spec already hinted at this but didn't > MUSTify it. > -- Mr. Alan Conway > > ------------------------------------------------------------| > > Document Name: amqp-man-v1 0-wd11.doc | > > Description | > > Updated error codes as per last TC discussion. For | > > operations using | > > identity or index lookup, using an unknown identity or index| > > key value MUST | > > return Not Found. Using an invalid index attribute name MUST| > > return Bad | > > Request. | > > | > > We talked about Not Implemented at the meeting but that is a| > > server error | > > and using an invalid index is a client error so I used Bad | > > Request | > > | > > I also added a general note that failure to include | > > mandatory attributes | > > MUST result in Bad Request also. The spec already hinted at | > > this but didn't | > > MUSTify it. | > > Download Latest Revision | > > Public Download Link | > > Submitter: Mr. Alan Conway | > > Group: OASIS Advanced Message Queuing Protocol (AMQP) TC | > > Folder: Working Documents | > > Date submitted: 2015-04-13 07:45:35 | > > | > > ------------------------------------------------------------| > > > > > ---------------------------------------------------------------------------- > > Deutsche Börse Services s.r.o. > Managing Directors/Geschäftsführung: > Michael Gassmann, Mats Andersson. > Limited liability company with registered office at > Sokolovská 662/136B, CZ-186 00 Prague 8 > recorded in the Commercial Register IC: 275 77 015. > Maintained by the city court in Prague, > Sec. C, File No. 116874. > > ----------------------------------------- > Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. > Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte > sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren > dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen > ist nicht gestattet. > > The information contained in this message is confidential or protected by > law. If you are not the intended recipient, please contact the sender and > delete this message. Any unauthorised copying of this message or > unauthorised distribution of the information contained herein is prohibited. > > Legally required information for business correspondence/ > Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: > http://deutsche-boerse.com/letterhead > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]