That's pretty vague, so I tried to look for specific uses that our current global state would prevent when embedding and problems it might cause when embedded. If I've missed some or if you have specific ideas in mind please feel free to send your own items too. Also one specific usecase of embedding could be #91

Global plugin state (the bit addressed by plugins: each plugin instance now has its own state #159) ties the lifetime of coredhcp to the program it runs in (or specifically, the end of the lifetime. You don't have to start coredhcp with the program, it can be initialized later with plugins.registerPlugins and server.Start). It prevents shutting down the server and starting a new one in the same execution, or running multiple concurrent servers, but that's just as true for coredhcp as it is now.
I think this one is definitely desirable regardless of embedding. It would unlock some usecases - notably running multiple servers with some shared state between them but not all, and for dynamic configuration reload. Some newer plugins already do that, and updating the others is a good idea too.
logging is also globally defined and prefixes etc are per-file rather than per-plugin-instance, so it has the same issue - changing this one I don't think would bring anything to coredhcp, but if there's a not-too-clunky way of addressing it that plays well with embedders, why not
The list of known plugins is global

coredhcp/plugins/plugin.go

Line 27 in a2552c5

var RegisteredPlugins = make(map[string]*Plugin)

Since go makes it very hard to load and (even worse) unload code at runtime, this seems harmless for embedding, once the code for a plugin is in the program it's fine for it to exist in that registry

Outside of the specific technical issue of global state, there are I think other questions that need to be answered first to understand what "coredhcp embedded in another executable" would look like and what interface the embedder program would use.

This is all pretty unspecified, and this discussion would benefit a lot from a concrete usecase in mind before we start making large changes without knowing why

Finally please note that right now in the current state of coredhcp, it definitely should not be widely used, and I'm not trying to encourage adoption and especially not embedding (we provide 0 API stability guarantees)

Remove global state #160

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions