OASIS Open Mailing List Archives  ·  All Lists  ·  amqp  ·  2012-04

amqp — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Request to add filters to public registry


Product names will have a large duplication problem. Two examples, our main product now "insight" is a common product name around the Internet ... also, the same filter used in multiple products will result in different names and/or confusion (we have three products ... POSway, BankLink, INAC that use the same base technology. Would suggest we stick with company names even though they change ... they're more unique and don't get marketing people trying to play games. cheers...angus On Apr-11-12, at 7:56 AM, Andreas Mueller wrote: > Would a symbolic name of > > swiftmq:jms-selector-filter > > etc also possible or must it be a domain name? > > A product name is more unique and self describing. Also a domain name may change (i.e. if the product is sold to another company) but the product name usually stays the same. Consequently the IANA PEN needs to be reflect the product name as well (if that is possible at all). > > -- > Andreas Mueller > IIT Software GmbH, Bremen/Germany > http://www.swiftmq.com > > Am 11.04.2012 um 16:36 schrieb Godfrey, Robert X: > >> Obviously very much in favour of getting these into the registry (and will - with my Apache Qpid hat on - ensure that they are supported in the Qpid/Java 1.0 implementation shortly). >> >> Two brief points: >> >> I think the symbolic names should be iit.de (since that will be guaranteed to be unique amongst organizations). >> >> We should probably also define a connection capability so that a client can indicate that it would use these mechanisms if available / a server can advertise their availability (this helps in the case where there may be alternate filtering mechanisms and the client can choose how to encode its queries as filters depending on which mechanisms a server supports). Thus I suggest also adding a connection property >> >> IIT.DE:JMS_FILTERS >> >> Which if present in the offered-capabilities field of the open indicates that the sender is capable of supporting the iit.de:no-local-filter and iit.de:jms-selector-filter filter types. (Note that not every node within a container may offer support for all filter types even if some nodes do support them). >> >> Thoughts? >> >> -- Rob >> >> >> >>

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]