Use OCaml to write plugins

[jchavarri]

I use Soupault as a library (from opam), and as I'm much more familiar with OCaml, I wonder if one could provide plugins directly as .ml files.

Besides familiarity, this could also lead to some performance improvements, and as plugins run pretty often, it would have some impact.

cc @aantron as we discussed about this on Discord.

[dmbaturin]

This is an intriguing use case that I didn't think was even realistic with the current state of the codebase.

Soupault was conceived as an alternative to Hugo and Zola that would be native and dependency-free, but also extensible. Embedding an interpreter for a half-decent general-purpose language was the only viable way to achieve that. To keep the thing type-safe and future-proof I chose to revive the then-defunct Lua-ML project (the PUC-Rio Lua breaks the bindings APIs between minor versions). This is the story behind the current plugin architecture.

For the Lua API, I make a stability promise. It's much harder to make that promise for the internal APIs. I'm planning at least one big change that will break all such plugins if any are written right now: migration to a newly-developed TOML library.

I'm not categorically opposed to the "soupault as a library" concept, but I'll need to know more about the needs of people who want to do that. There's no way all internal APIs can remain stable indefinitely, so we'll need to define a subset that plugins should be able to use without fear.

[jchavarri]

There's no way all internal APIs can remain stable indefinitely

But, for the "soupault as a library" use case, should they? I mean that, as a user, I would have similar expectations about Soupault APIs and plugins stability that I have with any other library: as long as there are no major versions, I assume the plugins remain compatible. And if there's a major version change, I would assume they might break.

[dmbaturin]

There were quite a few changes that would have required bumping the major version if the internal APIs were public. Soupault would have been at least at 5.x by now if that was the case.

Of course, as time goes by, that kind of changes is going to become less frequent. The TOML library replacement is the only big API-breaking change I'm planning now. Multicore-related changes will have no effect on the widget API. I can't think of anything else that certainly will break it.

So, until the new TOML library and the config handling changes that will come with it, using soupault as a library is going to be an "at your own risk" thing, but past that point, I suppose I can make it official.

I'd like to hear ideas regarding the public API subset though. There's no way every function can be in it, we need to think what will be in the public modules.