Having a more distributed model would allow a group of people to meet and share their music without needing to centrally update MetaDataServices or have shared file name space. It the most basic model, authentication could basically be ignored, or allowed by IP/MAC address, or a single shared password among a group.

Allow support for:

• Multiple MetaDataServices that store information about the songs
• Multiple players can connect to a single QueueManager
• Users can create and delete their own queues that allow streaming of songs over the network from KweerieClients
• KweerieClients and QueueManagers can discover MetaDataServices on the network
• negotiating authentication using SPNEGO and/or GSSAPI and eventually utilize Kerberos here at ACM, possibly using NTLM or plaintext elsewhere.

Multiple MetaDataServices require

• unique song identifiers that identify the database and the song. I'd suggest using IP address (128-bits for IPv6) and then an ordered 32-bit song id assigned when added to the database
• A way to differentiate trusted databases from arbitrary ones (symetric SharedSecret between QueueManagers and MetaDataServices
• MetaDataServices do not need to know about each other
• MetaDataServices can optionally require KweerieAuthentication, even to browse
• MetaDataServices do not need to know how many queue managers or clients are on the network
• share globally unique URLs (file://afs/acm.uiuc.edu/media/music* in our case) to allow players access to music
• provide support for music streams as well using specific URLs
• only allow a single MetaDataServices per unique IP address for simplicity

MetaDataServices would be able to:

• update own MetaData through whatever means it desires.

Clients would be able to

• discover MetaDataServices via DNS SRV or mDNS requests
• query and cache MetaData from the one seen on the network.
• vote using cached MetaData without needing to contact the MetaDataServices again for a period of time.
• create and remove personal queues as desired and as allowed and supported by the queue managers.
• optionally authenticate using KweerieAuthentication.

Queue Managers would be able to

• trust or don't trust certain metadata servers based on per-queue configured ACLs
• don't really need to know about particular MetaDataServices until a client makes a request that involves one.
• allow or disallow clients from voting with song ids from particular MetaDataServices based on dynamically configurable ACLs
• access data through a globally unique URL that doesn't need to involve the MetaDataServices