Object-based MMF Interface

[Mokhtar]

Just an FYI that I'm working on an SDK for plugging in new objects to the system. It's mostly for extension developers who want to specialize the API exposed by their objects, but it would also allow anyone developing generic C libraries to also use the various objects.

Sounds great. Would this make it possible to have two-way hooks with other extensions? (i.e. both exposing another extension's functionality to Lua and integrating Lua code as part of a external strategy/algorithm within another extension?)

[Retriever2]

I'm not entirely sure what you're looking for in the opposite direction. Are you asking about the ability to say .. directly invoke some Lua code from your extension (let's say for the purpose of making some part of your extension open-ended and changeable at runtime)?

It's possible for the SDK to expose that kind of stuff, sure. In the opposite direction you'll probably just skip the "bridge" module and work directly from your extension, but either way you'll have to manage the the presence or absence of dependencies since you probably don't want your extension to have a hard dependency on XLua.

[Mokhtar]

Yes that's what I will, potentially, want to do.

So, I take it that your SDK is for "embedding" XLua into other extensions rather than provide an API for it?

[Retriever2]

No, it's not for embedding XLua, it's exposing an API.

The usual use case is that you have an object that you want to control with Lua code, and so you would write a "bridge" module which interacts with both the XLua API, and a private API of your own extension that you make available to the bridge, and so neither XLua nor your extension explicitly depend on each other.

That may still be the way you want to approach the problem; instead of implementing the script-controllable parts of your extension directly in the MFX, you'd implement them in a bridge, and communicate across a private API. In this use case, you're utilizing an existing user-created Lua state that's more in the user's control than your own.

If you're really looking for a private Lua state that you have exclusive control over, then it would make more sense for your extension to link directly against XLua, and the API available to you would allow you to load code, set variables, invoke functions, etc. in that private state. This case is much more like "embedding" XLua, albeit as an external DLL.

If you have specific needs you'd like met for a project or you think I didn't adequately capture your use case somewhere above, you're welcome to PM me about.