Replace canHandleURL with a more generic detection mechanism

[hagabaka]

Currently YoutubeVideo defines canHandleURL to declare whether it can handle the Flash instance, by checking that the Flash movie matches ^http://www.youtube.com/v/.

To add support for new video services, this simple detection mechanism would not be enough. For example, some video players can be installed by the webmaster and therefore can have arbitrary names. More reliable detection for these players would be based on "flash args".

So instead of canHandleURL, we can just have a generic canHandle function. I propose passing the following information to it, as key-value pairs:

• playerUrl: URL to the Flash movie, as in the current canHandleURL
• domNode: the OBJECT or EMBED node for the Flash plugin
• flashArgs: the "flash args" defined on OBJECT or EMBED/PARAM, parsed into key-value pairs. This might not be useful for some video handlers such as the current YoutubeVideo, but it seems that YouTube embed code typically does not contain flash args anyway, so there is little extra overhead. Alternatively, We can provide a helper function to parse flash args, or just let individual video handlers implement it if there is little reuse.

This detection is mainly used to dispatch Flash instances into the right video handlers. For each Flash, each handler will say if they can handle it, and as soon as one handler can handle it, other handlers will be skipped for the same Flash. So if a video handler thinks it can handle the Flash instance but later finds out it cannot, it can just stop without replacing the Flash plugin with a video tag, and no harm is done unless the plugin could have been handled by another video handler.

[hagabaka]

Implemented at hagabaka/video5@ca77c53. Now a video handler define canHandle() as an instance method, so it can use any information in the instance, including the DOM node for Flash plugin and the player source URL, to determine whether it can handle the plugin. The start() method is only called if canHandle() returned true.

[drodriguez]

My view of this issue is that for now canHandleURL is enough for the majority of embedded video players out there.
The special case for JWPlayer is not the focus of the extension. Users of JWPlayer (or any other kind of Flash video player) will not ensure the posibility of choosing different formats of video (FLV vs. H.264). We know that YouTube, Vimeo, Dailymotion do, and those kind of video providers are the ones I want to focus on.
To sum up: I will like to stick to the current simple implementation based on URL, and when we find a video provider that needs something else (probably the flash variables or something like that), augment the API to handle it.

[hagabaka]

I'm not sure why JWPlayer support should not be included in the extension. JWPlayer can be used to embed FLV files, but my implementation tries to detect it through the filename, and leaves the Flash plugin alone unless the file extension is supported. Of course that is not perfect, as MP4 files could be named with other extensions, or for whatever reason, FLV files could be named .mp4, but for most situations, the JWPlayer support will work. This is an improvement for a user who prefers HTML5 video and often encounters JWPlayer embedding MP4 videos. Nothing is lost either for people who do not use JWPlayer.

[drodriguez]

OK. You are right. The intention of the extension is avoid Flash at all costs. Let me think about how to do it. Obviously you need access to the DOM element, but creating an object, only to call the “canHandle” method sounds to me like a bad design (but repeating code in the “canHandle” method and later in the constructor or the “start” method is even worse...).

[hagabaka]

Thanks for reconsidering this. I had also thought it was a little awkward to create the object and then check whether it can work, but I think it is still the better approach, even without considering JWPlayer.

The processes of checking whether the video can be handled and actually handling it will usually share information and work. Currently (in your tree) there is redundant code and work in YouTube and Vimeo handlers: they test the URL with a regex for canHandleURL, and then exec the same URL with the same regex to get the video ID. All information that can be obtained from test can also be obtained from exec. I think it's also awkward to pass the same URL twice, to canHandleURL and to the handler constructor. Even though one is a class method, they are in the same file and this could be avoided.

Of course, this redundancy is a bigger issue in JWPlayer, because checking for handleability is more work than a regex match, and this work needs to be done for actually handling the video too.

I admit "canHandle" is a bad name though. Maybe it could be renamed "canProceed" or "parametersAreSupported" or something.