I'm going to be implementing a Master Media Database whose primary purpose in life is to store unique identifiers and references to all pieces of Media spread throughout all of MP in one central location and associate "id tags" to said elements.
Imagine if you will a big physical CD album case on your coffee table with cards in each of the sleeves. Each card represents a particular piece of Media (a movie, a photo album, a Music Playlist, the latest episode of a TV recorded series). Now if you want to initiate playback of any of those items, you punch in the number on the card via your remote control or keyboard, or you run your barcode scanner over it, or if you're like me, you swipe the card over your RFID Reader, and magically MP starts to play it back.
There are two problems with this vision and the current state of MP.
First is that there currently is no central place to lookup a tag associated with any possible Media Type. Under the current architecture, I would need to know about each database type in advance and then add a table to each of those databases and then whenever a "tag" arrived, search each database trying to find which one had the "tag". While it would work, it's horribly inefficient, intrusive on the owners of the existing databases, and not very scalable because everytime a new database came online, my plugin would need to be updated.
Second there's no centralized way via an API call that I can find to tell MP to initiate playback of this Media Element. So let's say the end user requested a movie, and they were currently listening to background music from a CD. This request would involve asking the CD player UI to stop playback (allowing it to remember the point it was interrupted), have MP navigate over to the Videos UI and then initiate playback of the requested movie. The plugin would need to know how to properly stop each UI, tell MP to navigate to another UI, and then know how to initiate playback of the requested media in the new UI.
So I see the need for a Master Media Database coupled with some new methods that UIs wishing to allow playback of tagged elements would implement. At the least, this database would contain two tables. One that held all Media Elements that had some kind of a tag associated to them and their actual location in their "home" database, and another that held the tag to Media Element mapping. Each Media "silo", as I call it, that wanted the ability to tag the elements it stores for playback would via an API insert the element to be tagged into the Master DB and implement a UI to associate a tag with that element. Further, they would need to implement a way for an outside plugin to ask it to initiate playback of said media element (I have no idea what the best approach for this is), as well as for an outside plugin to request it stop playback and prepare to close.
In this "minimal" form the only items in the Master DB are the tagged elements. It does not contain a reference for every media element in all of MP. This is the level I intend to implement in the first round.
On the other end of the spectrum, this database is a fully indexed and searchable database of every media element MP currently has stored on any machine in the MP installation site and can adhoc aggregate new media "silos" on demand. I'm not going to implement this version any time soon.
For each Media Element how should I store the "local" reference? I was thinking the Element table would look like this:
| Master ID | UI Plugin Name | Media Type | Media ID |
Master ID - A globally unique internal number to reference this element
UI Plugin Name - The name of the plugin responsible for playback
Media Type - An indicator to the UI Plugin on how to interpret the Media ID
Media ID - The identifier the UI Plugin will use to uniquely identify this Element.
Both Media Type and Media ID would be passed to the UI Plugin when requesting playback.
I was thinking the "Tag" Table would look like this:
| Master ID | Tag Class | Tag ID |
Master ID - Same as above, the globally unique identifier for the Element
Tag Class - A "namespace" for the Tag ID, think of "RFID", "ISBN", "KeyedInput" as posible values for this field. A way for different input device types to prevent collisions in Tag IDs. Each "Class" would probably also have its own Process Plugin
Tag ID - The actual ID that the outside world would provide
In addition to this central database, I believe there should also be a central process that received these requests. External input plugins would submit their "Class" and "Tag ID" to this central process and it would handle the details of implementing the results.
I was thinking this is very much like a control MP from the Web Plugin and was thinking of trying to somehow use that model (if not that same plugin) here.
All input is much appreciated. I would especially like to here from folks on the UI side who can envision how I might go about actually implementing all of this. Specifically, how does an end user actually use the UI to associate multiple different tag classes and IDs to the same element knowing that some will be "read the next tag from the RFID Reader" or "Read the results of the next barcode scan" -- I guess a call back to the Input plugin of some kind... And how do we cleanly switch from playback of one media to playback of another...
Imagine if you will a big physical CD album case on your coffee table with cards in each of the sleeves. Each card represents a particular piece of Media (a movie, a photo album, a Music Playlist, the latest episode of a TV recorded series). Now if you want to initiate playback of any of those items, you punch in the number on the card via your remote control or keyboard, or you run your barcode scanner over it, or if you're like me, you swipe the card over your RFID Reader, and magically MP starts to play it back.
There are two problems with this vision and the current state of MP.
First is that there currently is no central place to lookup a tag associated with any possible Media Type. Under the current architecture, I would need to know about each database type in advance and then add a table to each of those databases and then whenever a "tag" arrived, search each database trying to find which one had the "tag". While it would work, it's horribly inefficient, intrusive on the owners of the existing databases, and not very scalable because everytime a new database came online, my plugin would need to be updated.
Second there's no centralized way via an API call that I can find to tell MP to initiate playback of this Media Element. So let's say the end user requested a movie, and they were currently listening to background music from a CD. This request would involve asking the CD player UI to stop playback (allowing it to remember the point it was interrupted), have MP navigate over to the Videos UI and then initiate playback of the requested movie. The plugin would need to know how to properly stop each UI, tell MP to navigate to another UI, and then know how to initiate playback of the requested media in the new UI.
So I see the need for a Master Media Database coupled with some new methods that UIs wishing to allow playback of tagged elements would implement. At the least, this database would contain two tables. One that held all Media Elements that had some kind of a tag associated to them and their actual location in their "home" database, and another that held the tag to Media Element mapping. Each Media "silo", as I call it, that wanted the ability to tag the elements it stores for playback would via an API insert the element to be tagged into the Master DB and implement a UI to associate a tag with that element. Further, they would need to implement a way for an outside plugin to ask it to initiate playback of said media element (I have no idea what the best approach for this is), as well as for an outside plugin to request it stop playback and prepare to close.
In this "minimal" form the only items in the Master DB are the tagged elements. It does not contain a reference for every media element in all of MP. This is the level I intend to implement in the first round.
On the other end of the spectrum, this database is a fully indexed and searchable database of every media element MP currently has stored on any machine in the MP installation site and can adhoc aggregate new media "silos" on demand. I'm not going to implement this version any time soon.
For each Media Element how should I store the "local" reference? I was thinking the Element table would look like this:
| Master ID | UI Plugin Name | Media Type | Media ID |
Master ID - A globally unique internal number to reference this element
UI Plugin Name - The name of the plugin responsible for playback
Media Type - An indicator to the UI Plugin on how to interpret the Media ID
Media ID - The identifier the UI Plugin will use to uniquely identify this Element.
Both Media Type and Media ID would be passed to the UI Plugin when requesting playback.
I was thinking the "Tag" Table would look like this:
| Master ID | Tag Class | Tag ID |
Master ID - Same as above, the globally unique identifier for the Element
Tag Class - A "namespace" for the Tag ID, think of "RFID", "ISBN", "KeyedInput" as posible values for this field. A way for different input device types to prevent collisions in Tag IDs. Each "Class" would probably also have its own Process Plugin
Tag ID - The actual ID that the outside world would provide
In addition to this central database, I believe there should also be a central process that received these requests. External input plugins would submit their "Class" and "Tag ID" to this central process and it would handle the details of implementing the results.
I was thinking this is very much like a control MP from the Web Plugin and was thinking of trying to somehow use that model (if not that same plugin) here.
All input is much appreciated. I would especially like to here from folks on the UI side who can envision how I might go about actually implementing all of this. Specifically, how does an end user actually use the UI to associate multiple different tag classes and IDs to the same element knowing that some will be "read the next tag from the RFID Reader" or "Read the results of the next barcode scan" -- I guess a call back to the Input plugin of some kind... And how do we cleanly switch from playback of one media to playback of another...