When posting, please don't make assumptions - ie, 'won't say that, it's obvious' - because it just might not be. Assume you're starting from a clean slate. This includes listing features from other clients - describe them in detail if you'd like to have them here.
Fuzzy deadline is October 20th.
Some good posts sprinked around the forum so far are:
by 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.
