The first item is exactly the reason for my earlier post on url parsing. Given that I cannot extend the FMSURL class and override parsePath. In documentation it suggests you should be able to customize how the url is parsed. I however do not understand how this is to be accomplished.
This is great feedback for us to get. Let me start with some high-level stuff, then I'll address the specifics of your cases.
There probably are places in the framework where certain methods or properties ought to be exposed to increase configurability. The way we'd like to address these is to focus on specific use cases that can't be solved within the framework (and thanks for providing some), but which would be made possible by loosening the access specifiers. In general, when making a decision between public vs. private where no specific use case points one way or the other, we are always going to err on the side of making things private. Every method that is public or protected will need to be supported now and forever (*), whereas private methods can be removed, refactored, etc. The smaller the public API, the more flexibility we have to change implementation, restructure code to improve performance, etc. If we can address your use case without having to expose a larger API surface area, then that's the best of all words since we can retain that flexibility going forward.
To your use cases...
VideoAdElement: This type of use case ("decorating" a MediaElement to augment or modify functionality) is a common one, and we've come up with a specific approach for this type of problem involving the ProxyElement class. The basic idea is that you can wrap your MediaElement in a subclass of ProxyElement, and layer additional functionality on top of the MediaElement via the ProxyElement subclass's implementation. To the client of the ProxyElement, the behavior is the same as if they were working with the wrapped MediaElement.
For example, you could create a VideoProxyElement which extends ProxyElement, and which wraps VideoElement. When a client attempts to load the video (via the ILoadable trait's load method), your VideoProxyElement can intercept the call (by overriding the ILoadable trait) so that it gets a chance to rewrite the URL before the video's load begins. I've attached a ZIP file that demonstrates this: it has three classes, but the one you would use is VideoProxyElement. VideoProxyElement automatically rewrites the URL to point to a different one (in my sample code, a progressive video on Akamai's network). If you were to assign a VideoElement that had a stream URL:
mediaPlayer.media = new VideoElement(new NetLoader(), new URLResource(new FMSURL(REMOTE_STREAM)));
Then this would (obviously) play the stream. But if you wrap that VideoElement in the VideoProxyElement:
mediaPlayer.media = new VideoProxyElement(new VideoElement(new NetLoader(), new URLResource(new FMSURL(REMOTE_STREAM))));
Then the MediaPlayer will play the progressive video rather than the streaming video.
The neat thing about this technique is that you can define a ProxyElement that does any sort of preflight activity you need, without having to touch the underlying VideoElement. The functionality is simply layered on top. And (as we'll demonstrate in our next release), you could include VideoProxyExample in a plugin so that the player doesn't need to know any of the details (it just needs to load the plugin up front).
Hope this helps,
(*) Once we commit to being backwards compatible, which us unlikely to happen before the version number approaches something much closer to 1.0.
VideoProxyExample.zip 1.8 K