Cross-platform C Plugin Template Repository

[louwers]

Here I'd like to sketch out some of my ideas for the setup of the C plugin API. The target user that I have in mind is Android and iOS developers that do not neccesarily have deep knowledge of native development and related build tooling or graphics engineering. This forms the bulk of our user base. They should still be able to:

• Create their own (cross-platform) plugins.
• Use existing plugins that other community members created.

The way I imagine this: set up a template repository that takes care of all the build tooling. You should just be able to plug in your credentials and kick off a workflow to publish your plugin. The repo will have an AGENTS.md file so you can go to town and experiment with writing plugins using LLMs.

When it comes to the C plugin API itself, what the extension points should be and how to allow for runtime loadable plugins, this is still somewhat of an open point of research and discussion. Although HudHud (specifically Malcolm Toon) already did a lot of leg work here which we will be able to reuse.

If we'd put it in a user story, a good one I think would be "As a MapLibre Native user, I want to be able to vibe code and publish a contour plugin that is usable on iOS and Android".

[HarelM]

As an experiment I did the following:
I wanted to read PMTiles from a file.
This is not using maplibre-native APIs, but a very simple use case for sharing code between iOS and Android to support offline capabilities in maplirbe-native (using http interceptor).
Here are 3 reference implementations:

1. C/C++: https://github.com/Mapeak-com/pmtiles-mobile/tree/98c181cebde6896ada8b5d6185e83b3c22fe1275
2. Hand written rust code + uniffi: https://github.com/Mapeak-com/pmtiles-mobile/tree/8c2375e5109c9229d5727127026b18b0e9d32455
3. Using pmtiles2 crate + unitffi: https://github.com/Mapeak-com/pmtiles-mobile/tree/fd6a838a651ebc5811fba4dadaa77ffd3fcce052

It might not be a great test case, but I think we can get inspiration from the project structure, amount of files, complexity etc to be able to create a template that can use useful.

Another Idea is to have move than one template - one for c++, one for rust, one for KMT. But it might be a lot of maintenance work...