1 person found this helpful
I don't think this is in our documentation (at least I couldn't find any references). So here's a simple summary:
- Use static plugins when you want to ensure the code is loaded and ready on startup, and don't want to incur the initial time cost of loading the plugin dynamically.
- Use static plugins when you want complete control over versioning of the plugin. The plugin provider can't push a new version to you without your consent/knowledge.
- Use dynamic plugins when you want to swap plugins in and out of your player without having to change what you're linking into the player.
- Use dynamic plugins when you want to receive updates to the plugin immediately upon their being made available. If you're a plugin provider, a dynamic plugin allows you to "upgrade the world" just by updating the SWF on your server.
Thanks! The simple summary that you provided is excellent.
The initial summary is from a player creator's perspective (aka plugin consumer). In this case my bias is to default to using plugins "statically", i.e. compiled into the player.
Might you (or others on the list) know of current or forthcoming plugins where the plugin publisher only supports dynamic loading? And what their requirements are for only making the plugin available for dynamic loading?
Thanks again for your great support.
As product manager for OSMF, I've had a number of conversations with partners and customers about this. I'm not aware of cases where plug-in providers are supporting only dynamic loading. In my experience, plug-in providers are pretty flexible depending on their customers' needs, rather than supporting just one approach, and I've heard from some customers that want static and others who want dynamic.
It's important to note that dynamic loading doesn't specify where the plug-in is hosted. It's possible for the plug-in provider to host and control versioning, etc., but I see cases where the plug-in provider doesn't want that responsibility, and the publisher doesn't want to risk that the plug-in provider might deploy an updated plug-in that breaks their player. In that scenario, the publisher is hosting the plug-in on its own servers, even though the player is still loading the plug-in dynamically.
As a 3rd party vendor, I'm inclined to offer only dynamic plugins due to the fact that we're often rolling in new functionality and/or fixing issues and do not want to deal with each publisher having diff't versions or having to distribute new static plugins to each publisher as we make one of these sort of changes.
While I can appreciate the benefits of the elimination of run-time loading that comes with dynamic plugins, the benefits of dynamic plugins from 3rd party vendors outweigh the "cons"
In response to the mention about the publisher not wanting to "risk" breaking the player, I suppose that is a concern if the plugin being used is absolutely necessary for the overall functionality of the publisher's player, but I'd hope that the OSMF plugin framework is handling any fatal errors from a plugin such that they do not kill the player
VP Product & Technical Operations