The Leap Motion discussion got me thinking more about Cesium plugins. I want to bounce around a few ideas for creating an ecosystem of plugins that live outside the main Cesium repo like Leaflet plugins and GeoServer modules.
Each plugin would be a self-contained feature like a new input device, imagery provider, material, or post-processing filter. These would be listed on cesiumjs.org and meet some basic standards, e.g., doc for integrating with a Cesium app, but wouldn’t be as rigorously vetted as core Cesium code.
This would allow us to:
Avoid bloating Cesium with large third-party libraries and non-core features, e.g., I would move some of the rarely used materials to a plugin.
Lower the barrier for non-core contributions by eliminating the need for a CLA.
Give us flexibility to release experimental plugins early before committing to a core-feature.
This would, of course, create some segmentation; plugins would be independently maintained, hosted, and licensed, and potentially tied to specific versions of Cesium if not kept up to date.
Are folks interested in this? What other ideas do you have? Is anyone interested in flushing this out and running with it?
I believed that a plugins eco-sysytem would be necessary to make Cesium a great tool ! I wish I could add new ImageryProviders, new material/Apperances, new vector symboloy, new vector data source, even new terrain tile rendering algorithms through well-defined specification, rather than dive into the core cesium source code.
An other idea. Since Cesium is a tool for presenting geospatial information, wish it organize the scene through common mapping concepts, like map, layer, just like OpenLayer, Leaflet, or osgEarth did. I wish to move all my work based on these SDK to Cesium, though a lot of work ahead.
Thanks for your great work, including the great book and great software! I learned a lot from it. Wish happy new year!
Just so we’re clear, Cesium already has well-defined interfaces for imagery providers, appearances, etc. so new ones can be added in an isolated manner. What Cesium doesn’t have is a way to distribute these new additions without including them in the main Cesium repo. What I’m suggesting by Cesium plugins is a central place to list and promote these new additions, i.e., a website like Leaflet’s, and some quality guarantees, i.e., that listed plugins follow a few guidelines like they have doc and an explicit license.
Yes, I 100% agree. Cesium is great and has a nice core set of functionality, but I think it needs to stay clean, and a way to centralize plugins people develop would be very welcome (and welcoming). As you say Patrick, Leaflet has an excellent example of this and I think we could easily model Cesium’s after it.
I think your segmentation concerns are valid, especially with the rapid rate of Cesium development and possibly breaking changes. But in the end I would think you have to leave it up to the community to get newer versions of the plugins out there and updated if there’s a breaking change. As far as a vetting process, I would think it would need to be pretty basic, I’m not sure how detailed the Leaflet people go, but I can’t imagine they go and test every single plugin, or maybe they do so once. Ultimately its up to you guys, the maintainers to pick something that’s right for you. Basic requirements to post might be:
A decent README on how to use it.
Open Source? Up to you guys on whether you’d promote other people’s closed source plugins on the site, I would think not.
A note in the readme that includes what version of cesium the plugin was tested on
I honestly don’t think much more would be required. Tests would be nice, an AMD compatible library might also be nice, but probably not required.
My two cents, I’ll be a guinea pig and propose my Leap Motion plugin as a first submission. Looking at it now, and my proposed requirements, it needs a note on what version of cesium it is compatible with, which I’ll fix now. https://github.com/Aviture/cesium-leap
Thanks Mike. Given this discussion, here’s what I propose:
What: A page on cesiumjs.org with a list of Cesium plugins: Plugin name, developer, screenshot, description, and link to its site.
As mentioned before, plugins will keep core Cesium small-ish, lower the barrier-to-entry for contributors, better promote contributors, and help us build an ecosystem of useful libraries. We’ll promote plugins using our normal channels: the website, blog, twitter, this forum, etc. If there is interest from all parties, some plugins may become core Cesium features (and vice versa on occasion like a few of the obscure materials), but do not have to, nor do new features need to start as plugins.
Criteria: A Cesium plugin just needs (1) to be useful to the Cesium community, (2) to state what version(s) of Cesium it is compatible with, (3) documentation for install and usage, and (4) an explicit license.
(1) This is obvious I suppose, but a plugin doesn’t need to be graphics related. For example, it might just be a function to compute the area of a polygon.
(2) It is up to the plugin developer to keep the plugin up-to-date with Cesium. I expect this will not be a problem for popular plugins.
(3) The doc style is up to the plugin developer, but many plugins will get away with a simple README.md. It just needs enough info that the typical Cesium developer will be able to download and use the plugin.
(4) We like the Apache 2.0 license, but a plugin can use any license the developer wants, including a closed-source license. It would be completely OK for someone to release a commercial closed-source plugin and sell it. I expect this is most likely for plugins for niche vertical markets.
We’d ask, but not require, that the plugin public interfaces be similar to Cesium’s so users know what to expect.
I’d like to keep the barrier to entry as low as possible to start. If the plugin ecosystem becomes the wild west and users have too much trouble using plugins, we’ll adjust the criteria as needed.