External Modules

[ixokai]

I know this may be a difficult or complicated thing to implement ultimately, but I believe its important.

The Mudlet community seems to growing, and its starting to grow a community of modules that people have available, and that's really awesome.

There's a few systems in-development or released, by a few different people, and more and more interest it seems in these. I have my own system I'm working on, and it does some things very well-- some things which aren't entirely tied to it. My queue system for one, my action system for two, and the queue-dependent influencing code. Although I could release all of this (when its done) as a complete system, in reality its component parts. And I'd like to release it -as- parts which people can use and intermix as they see fit, and I'd like to use other systems-- GUI's, curing-- that I don't really want to develop myself, by others, along with my core system.

But in such an ecosystem where people are using various systems by other people, the fact that everything is bound into a single profile is very problematic. Most of my core code, for example, isn't really specific to Lusternia (the only mud I presently play), but can be used in any. I can import it into each profile I use, but this creates a burden to keep these updated in each and every profile. Additionally, it becomes complicated to update such modules when new releases are made.

I propose that Mudlet should grow an ability to link to external "packages" in a profile. For normal, regular users, doing simple things, they never need to worry about this. But for the more advanced person, it would allow them to "link" to data which is stored externally to the profile itself.

A package is a scaled down profile; it doesn't contain any connection information, only aliases, triggers, scripts, and such.

You "link" to a package, and the contents of that package are included in the current profile. The profile has a set of triggers, the packages have their own set, which are loaded into the temporary or current set of triggers in the active package. You should be able to edit that package directly: in the 'Triggers' UI, it has that 'Triggers' label on top. I proposed that if packages are linked to this profile, another such label will exist for each package linked, and you can go in and edit those. Saving those items will save not to the local profile, but to the package itself.

In this way, developers can share their 'package' specific information by simply uploading the XML, with the 'local' details being separate. It would greatly enhance the ability for developers to work on code and release it, keeping separate the release-able portions from the game/profile specific information.

Thoughts?

[Vadi]

Look at Lua Rocks. Back when we thought about the packaging system some but discarded as being too early in Mudlets development stage, I did some research (well, mainly tries to see if apt would run on windows and tried some mono packaging thing...) and settled on lua rocks as being the best solution for the distribution of packages.

I think that, integrated with your linking idea, would actually be quite a fully-featured package solution.

[Heiko]

Such a feature needs careful planning. Suggestions are welcome.

[fxf]

I wonder if it is possible to keep scripts in external lua files and just use lua's "require" keyword for them from Mudlet. That way I would create for example "keypad.lua" containing script which creates key bindings for numpad walking and each time I change this file it would be automatically updated in all MUDs which "require" this file.

Is this good solution? Of course this doesn't solve problem of external modules from other people, and it is sort of workaround which skips Mudlet's style of writing aliases, triggers, etc. and storing them in XML files. But I personaly prefer to edit lua files in external editor, rather than using Mudlet's GUI for anything more than some simple temporary things.

[Vadi]

That's a different topic really. Here, this is more like a packaging system for mudlet scripts.

[fxf]

That's a different topic really. Here, this is more like a packaging system for mudlet scripts.

My point is, that if you use just Lua scripts and not Mudlet xml files, you already have the ability to use one script in multiple profiles, load and mix different (Lua) libraries, etc.. On the other hand, you can only import Mudlet xml, but the changes made in one profile are not automatically propagated back and used in other profiles - that is, at least IMHO, what ixokai meant.

[ixokai]

I don't really want to use external lua scripts; for one thing it has certain cross-platform complexities, for another it makes editing the code quite difficult, unless the script editor somehow becomes able to edit external files.

Its possible to do a pure-Lua 'mudlet' package, requiring that the developer only use tempAlias/tempTrigger/etc to create the integration functions, but I'd rather not see that. I'd like Mudlet packages to be a collection of triggers, aliases, scripts timers, and such. "Lua" code is just one component. Some people like to code systems which are heavy on code and defining everything in code-- yes, me!-- but some people would rather code systems which are alias or trigger heavy, and would like to use the built in alias/trigger UI to create such.

In that vein, I honestly don't understand what lua rocks brings to the table and makes easier. The project seems to be trying to be a CPAN, Ruby Gems, or Python setuptools+eggs, which are all about installing external modules into a system lua. But we're not a system lua, we're an embedded lua. I'm not sure if we'll ever be able to really support automatic inclusion of third-party Lua modules available as rocks, as a great deal of them are implemented in C-- and one must operate on the assumption that windows users are incompetent to compile, and mac compilation is a complete nightmare. (though its something I want to work on documenting more directly) The addition of dependencies for a cross-platform app therefore must be handled by the maintainers.

We'd have to set up our own "rocks" style repository, and maintain it. While that's possible, I'm not sure if its really worth the cost-- yes, it'd be nice to allow automatic dependency resolution, to allow a user to click a button and say 'install', search a list of packages, and select one... and if that's the kind of system you want, so be it! Its nice. As a user, I would be just as happy with a simple website (though, ideally, not a forum) listing various codes people have released, and downloading those into a certain directory, and downloading the dependencies, and then marking in my profile that I want to include them.

Especially since rocks seem to treat non-lua data as an afterthought: its possible to include such files, but for Mudlet 'scripts', that data should actually be a first class citizen.

From both a user and developer (mudlet script developer, not mudlet developer) I'd be quite satisfied with manual dependencies. If you think we need some sort of automatic dependency resolution and installation system a la lua rocks, that's fine

But what I envisioned was a "Mudlet Package" directory, which would be platform-specific unfortunately. On mac, it certainly belongs in ~/Library/Application Support/Mudlet/Packages. On Windows, its probably best to put it ~/Documents/Mudlet/Packages. On Linux, I'm not sure. But probably ~/.local/Mudlet/Packages.

Each package is an XML file, similar to a profile. In fact, its the same basic structure, just leaving out connection-esque details.

A package should also include a section which says which packages -it- depends on: if they don't exist, it shouldn't be loaded. This is recursive. If version requirements are needed, I think its sufficient to have a global version variable and simple <, <=, =, >=, > operators, which shout when someone loads a package which doesn't fulfill the requirements. I'm not sure if its really worth it to include such a feature, though.

Profiles would grow a similar section, which lists what packages it depends on. The difference would be, a profile wouldn't refuse to load if the packages aren't available-- it'd just display an error. For a user interface, the script editor should grow a 'Dependencies' tab. This would list all the packages in the package directory as a checkbox list. One can then simply check/uncheck which to include in this profile.

Now, for implementation: I'm not entirely clear on how Mudlet is implemented internally, as I'm not a real developer, just a port maintainer. So I can't speak to specific implementations, but the strategy I have in mind sort of depends on how the data is stored internally.

I'm picturing it either as a tree, or a series of tables, one for each kind of data. Either way, each item would gain a 'source' tag which would be either blank, or the name of a package.

When you load a profile and it loads the packages, it adds all the items to the appropriate data structure, marking the package name as the source. So if my package has an alias 'Blast', it adds it to the aliases data structure. Here the question of uniqueness comes to mind: what if there is an alias with a name of 'Blast' in the profile or another package? They shouldn't overwrite, but I don't know enough about Mudlet internals to suggest how to handle this condition.

When a profile is saved, the data structure is iterated over; only those items with a blank source are saved to the profile XML. But this is important: the packages should still be editable in-Mudlet, and thus everything should still be saved out. But that just basically means there would be a multi-pass of saving; the first time it'd write out everything with a blank source, the second everything with a source of 'Mantis', the third everything with a source of 'ixokai_equilibrium_queue', the fourth, etc. Now you can surely do that with just one sweep if you want, but you get the idea.

In the UI, package-item should be separate from profile-items; I'd propose that for example the top of the 'Triggers' list says 'Triggers' with a yellow background. That's for profile triggers. At the end of them, another header in yellow should exist for each package, named for said package, to contain the other triggers.

And.. them's my thoughts.