publish
    - fail if no queue
    - fail if no consumers
    - fail if no subscribers

content based routing
    - message field table
    - matches subscription/consumer field table
    naive implementation:
        - match each field
    fast implementation
        - bitmap matching

    - consume has list of criteria
        - ALL must match
    - message has list of criteria


    consume-> parse ->>> criteria
    message-> parse ->>> criteria

    using bitmaps lets us find all consumers that match each
    criteria in a message.

    how to define messages that match ALL criteria in each
    consumer?

    - get bitmaps
    - accumulate into array
    - array > 0 indicates consumer numbers
    - nbr hits -> OR or AND
    
queue index
    - each subscription queue has a unique index
    - this is a low number - 0 to IPR_BITS_SIZE_BITS-1
    - hash queue address -> index & find spare slot
    - at queue destroy time, clear slot to zero
    OK
    
matching engine
    amq_matcher
        - key (name, value, type)
        - data: ipr_bits_t *
    OK
    subscription new
        matcher parse topic pattern
        add reference to subscription
    OK
    subscription destroy
        clear from all match entries
    OK
    
publish
    - find match entry
    - send to all subscription
        - filter on no-local subscription


durable subscriptions
    - stored in subscription table
    - rebuilt when server restarts
    - not deleted when consumer disconnects
    

dest_new
    - if topic service
        - match to all existing consumers
            - possibly extend consumers criteria

dest_destroy
    - if topic service
        - remove criteria from database


in dest_new
    - validate dest name using regexp


mailbox concept
    open handle, create mailbox
    purge at open
    purge at disconnect
    private (take ownership)
    template (name)


temporary queues
    - explicit clear option
        - by any consumer
temporary subscriptions
    - explicit clear option
        - by consumer
persistent subscriptions
    - saved in db_dest
    - consumer must also be saved
    - and recompiled when server starts








consume -> update subscription set
    implementation 1 - quick&dirty:

    request object
        - topic name
        - subsc reference

    handle consume on topic
        - calculate full topic name
        - create request object
        - add to vhost list

    handle send
        - check all request objects
        - distribute messages to subscs
        - dispatch subscs

    implementation 2 - faster matching
    - kill request object

    handle consume on topic
        -


vhost->queues   accept, dispatch
     ->topics   accept
     ->subs     dispatch

    smessage-> topic, queue
    dispatch-> queue, sub


Stuff to fix

 - complain if config file is invalid (says nothing)
 - change temporary queue to "mailbox" concept
    - purge at open, optional
    - purge at close, optional
 - move to HUGE values for file/mesg sizes
    - or 64-bit values
 - way to cancel and/or purge a message being sent
    - HANDLE STOP / PURGE command

Queues
 - deleting - need to handle extent files as well...
    ... does not appear to create them?

restartability
    . refresh virtual hosts
    . create new queues & topics
    . leave connections alive

subscriptions
    . subscription table
    . persistent / non-persistent
    . each subscription is a queue

- amq_server object
    - replaces amq_global
    - runs on a specific port



- move argument parsing & copyright block to standard iPR function




Changes

    rfc006
    fragments
        - allow client to cancel messages using flow/cancel

    client failure
    - failover to secondary server
    - use heartbeat command to check server is alive

    clustering
    - n servers
    - queue + consumers on each server
    - if queue filled & no consumers, messages are forwarded
        - using inter-server MTA
    - if queue empties & consumers, messages are scraped
        - using inter-server MTA
    - separate mechanism for forwarding topics
    - client connection
        - list of ip addresses
        - serial or round robin
        - can be redirected by server
        - can tell server, "no redirect"
    - durable subscriptions
        - may be held on different server, use queue thunking
        - may be allowed for scalability

    multithreading
    - one for smt
    - one for bdb

    clients, priority
    * COM+ for demo
    * C thread-safe
    * Java
    - .NET
    * Perl


Durable Subscriptions
    When server starts up, creates consumer item for all
    durable subscriptions it finds...
        - these are destinations marked as SUBSCRIPTION


Clustering
    a. for resiliency (failure)
        - using master-slave model
        - possibly hierarchical model
    b. for load-balancing
        - using multi-master model
        - possibly hierarchical model
    c. for geographical distribution
        - using other means
        
    - client connects to server
    - server can kick client, with 'reconnect to different server'
    - server provides list of known alternative servers
        - masters and backups
    - client may try servers randomly/serially
        - this is for load-balancing
    - client can connect with 'please don't kick me'
        - if it was already working with that server

    master-slave:
        - agressive heartbeating allows slave to monitor master & vv
        - various strategies for replication
            - repeat all AMQP commands to slave
                - get confirmation before doing own processing thereof
            - repeat internal structures to slave
                - all created objects replicate themselves
            - repeat only stored data
                - messages, subscriptions
       

    amq foundation
        - charitable status
        - educational charter
            - promote the development & use of amq protocol, software, etc.
            - may assist with any legal costs associated with use of amq
        - board members
            - sponsoring companies
            - industry partners
        - rules & regulations
            - adding new board members
            - annual meetings
            - accounting procedures
            - donations
            - termination
        - funding
            - sponsorship & memberships
        - voting members (council)
        - non-voting members (assembly)
        - board (...)
        - chair, treasurer

    
