[please comment] package sharing solution

[Caled]

I realise that this has been a long-standing request, but I don't think that this particular solution has been posed before. I really wish I was able to at least make a start on writing the function, but I don't have the necessary knowledge.

As I understand it, package building and sharing solutions to date have focussed on a GUI solution for it.

Instead, a function that reads information in a table, and then builds the package based on information in the table. It is quite fair to require that only whole class objects be exportable.

Code: [show] | [select all] lua

packageName = {
 Triggers = {"Trig class one", "Another trig class/I want in my package/Which has a path"}
 Aliases = {"The alias class with the aliases I need in the package"}
 Scripts = {"The scripts are in this script class"}
 }

function buildPackage( package, filename )
    -- Whatever code will mine the xml file for the stuff defined in the table, and shove it into a new package.
end

Do you think that would be difficult? It isn't a perfectly noob-user-friendly GUI solution, but it sure would be easy enough to use, and dead useful for most of us.

[Heiko]

An advanced package system needs to be able to handle package updates automatically i.e. install and uninstall packages. Right now we do not have the concept of "package" in Mudlet just the concept of content.

A simple solution would keep a record of the installed packages. When a package gets upgraded or uninstalled, Mudlet would simply remove all object parent folders that came with the package. This would handle the case where users cherry pick some elements from the package and moved them into their own system and uninstalling the rest of the pacakge. If we kept a record of all installed package items, this wouldn't be possible.

This solution is trivial and speedy to implement and serves most peoples' needs in my opinion.

[tsuujin]

Wouldn't it be an easy to fix to simply add a "package" flag to all current system elements (triggers, aliases, timers, so forth) and be able to specify that element as part of a package? This would make parsing the system to find items in that package exceptionally easy for any task, including updating.

[Vadi]

That's a great idea tbh.

[Vadi]

I'm liking this so far:

'When a package gets upgraded or uninstalled, Mudlet would simply remove all object parent folders that came with the package. This would handle the case where users cherry pick some elements from the package and moved them into their own system and uninstalling the rest of the package.'

That covers installation and uninstallation, possibly upgrades if we consider an upgrade if we consider an upgrade where the groups with the same parent name will be deleted and new ones added.

There's also a case of enabling/disabling packages - although in Mudlet, just disabling the parent groups would work.

Lastly, creating new things in a package / copying between packages is something that'll be necessary... but I don't have ideas for at the moment.

[Hadoryu]

Hello everyone.

I've taken a look at Mudlet recently, with plans to 'port' a curing system to it from MUSHClient (link: http://forums.aetolia.com/index.php?/to ... ntry363398).

My intent is to keep the core logic separate and create abstraction layers for MUSH and Mudlet, allowing me to update a single version that works on either client.

To move on to the main topic though, when I got into Mudlet, I found I couldn't really have a plugin/package that can be installed/uninstalled/updated. And I was pointed to this thread, subsequently, so here I am. To cut to the chase, I'll list some of the things I feel a package management system can implement to make the client better.

These being:

- Sandboxing.
When you're juggling large scripts on the same system, you have a great deal of opportunity for doubling up variables, if nothing else. This can be a nightmare to debug for someone maintaining a package and it's safe to assume a lot of the general users that will be using a script won't be the same people who would be maintaining it. By default, I think it's important for package namespaces to be separate from each other and from the main script. The option to address the namespaces of other scripts/packages should probably still be an option for interoperability. Sandboxing should include things like script-generated triggers as well (they should be created within the plugin/package sandbox, not the main script), should limit access to resources outside of the plugin/package - you don't want any plugins to be able to reach out and do anything untoward to your main script.

- The ability to deactivate/reactivate entire packages.
From what I see in Mudlet's current interface, there isn't any by-package separation. Rather, things are sorted by aliases/triggers/scripts. This is probably sub-optimal for packages altogether, as they tend to be made up of all of those components. Perhaps a separate 'packages/plugins' tab to work with them? There is also a good deal of information a package can carry that would warrant having a separate screen for it - version, instructions for usage, author, content statistics and such. For readability reasons, it might also be good to not dump all the scripts/aliases/triggers into the user's main scripting screens, but instead leave them as sub-options to each package. A sufficiently large plugin can have a thousand triggers. Grouping does help clean things up a bit, but those screens don't (of course) show which group belongs to which package.

- Versioning, unique identification and updates.
You probably want to avoid the possibility of plugging in the same package twice, or two different versions of the same package. MUSH solves this by giving each plugin a long id, which seems a simple enough approach. Something MUSH doesn't do is really use the package/plugin version for anything other than developer information. It could be beneficial to have Mudlet be able to tell which version of a particular plugin is newer, to avoid having to have the user open files and read direct in the XML.

In general, I consider package management of great importance for a modern client, especially one with Mudlet's growing (and well deserved) popularity. The ease for plugin developers can determine the amount of plugins available along the road and the ease for users can greatly enhance the client's friendliness. The possibility to 'install and forget' can make the client much less intimidating.

[Vadi]

I agree on other points, but not sandboxing. We found that letting the script authors do it themselves (http://forums.mudlet.org/viewtopic.php?f=8&t=1211) is less stressful for writing / more beneficial for interoperability.

[Knute]

As I was reading this posting, I remembered a game that I used to play... Morrowind... There were tons of mods for the game, and there was even a program or two that you could use to install/uninstall various mods that would keep track of all the bits and pieces so that you could easily install, and then uninstall them if you wanted.

Is that what's being requested here?
If so, then you are looking for something to keep track of the aliases, and triggers and scripts and such as they are installed/exported/changed/modified...

[Vadi]

Pretty much.

[tsuujin]

I don't see a need for mudlet to track version numbers at all. Updates should clobber old information and install on top, rather than worry about parallel installs and version tracking.