Reply to thread

Message: <blockquote data-quote="MariachiElf" data-source="post: 55067" data-attributes="member: 20753">tomtom,Thanks for the comment.I'm going to skip over 1 as I think we both can agree it's mostly irrelevant.  Think of the remote controls or skins that MP supports that almost nobody but the author will ever use.  That doesn't mean the author shouldn't develop them, or care about clean implementation.Further the "no large audience" doesn't particularly apply since this is not about RFID, it's about a new type of input method and that effects every MP user in one way or another.If you really think I'm being to light about the "audience size" consideration please bring it back up.As for 2, yes, you understood my motivation project correctly.No, I would say it's not easier to insert the CD into the tray than it is just to wave it front of the player (from a what does the human have to do to play this thing perspective).  Aside from all the extra hand movements (which btw I don't trust my 1 1/2 and 4 1/2 year olds to execute properly which was the whole motivation of getting an RFID solution to begin with), you also don't need to leave the CD in the tray.  You can actually put it back in its home right away, while it's still in your hand, making it easier to keep it where it belongs.Also, an offline search engine isn't really what this is, it's more an "external search engine" and/or Command association.  I mean that in the sense that MP wouldn't care where these external identifiers came from.  It could be an online DB, it's just not a DB under MP's control, and that's the distinction.You could initiate playback of a Media Element by entering it's ISBN number which was fed in through RSS.  Perhaps MP is integrated with a picture sharing website, and part of the problem is you need to map the ID the website thinks the picture or photo album is to the ID inside My Pictures in order to synchronize them.Perhaps the Media Element in question is actually a Script of some kind from the "My Scripts" Plugin.  This engine would allow an external input device (be it physical or virtual (like a network service plugin)) to uniquely identify the script you would like executed and execute it when the right circumstances appeared.It's an MP automation component and external identifier mapping component more than anything else.This could make MP a generic back end for initiating playback of media without having to use the MP UI directly which makes MP more of a platform then an app.Think of an application that implemented some completely different view of the MP Element universe that would be completely inappropriate for the MP UI.  For whatever reason, writing a UI plugin to MP just isn't the right answer.  However, that implementor doesn't want to rewrite all the media handling specifics the Plugin writers have already solved.  That implementor just wants to maintain their own database of Element identifiers and send those IDs to the MP machine at the appropriate time and have MP "Do the right thing (tm)".  That's the kind of thing that this concept is enabling.  My examples are just what I see as useful, and they might work for you or they might not.  Just think of any reason you might ever want to be able to cause MP to playback a Media Element by submiting an Identifier that MP didn't control the creation of.Does that change your opinion at all?</blockquote>

Verification