Zipped-up plugins

This is really just the latest idea come from an ongoing thought flow, on making it easier to distribute plugins and/or communicate between them. Tired of me yet?

I know of several plugins that require certain resources (such as images), and I'm sure there will be plenty that also have sqlite databases distributed alongside. I personally have quite a few plugins in my plugins directory, and it's getting really disorganized in there. My idea is to add support for zipped plugins, where the plugin is pre-packaged with its resources, and you only need to move around the .zip file itself.

The idea comes from Java's .JAR format. A MUSHclient plugin archive (.MPA?) would simply contain the plugin's .xml file (either named identically to the zip, or something standard like plugin.xml), as well as the plugin's resources, such as images or databases.

Theoretically (and this part is more of an afterthought) you could change the contents of the ZIP, perhaps saving an updated database into the archive, or 'require'ing a file from it (to serve the same purpose as my LoadPPI script from before, but without having to wait until the other plugin has loaded). I know Java has support for this sort of access in its java.util.zip package, but I don't know how easy it would be to implement something similar in C++. I think this particular facet would make zipped plugins even more useful.


In summary, zipped plugin support will allow plugin resources to be packed alongside the plugin itself, keeping things organized. And letting MUSHclient modify the archive's contents would add an unprecendented level of ease of use. I really think this would be a great addition, and I hope it's not too hard to add in any form.

I'm sure this is a stupid idea, but couldn't you use serialize on install to put the files where you want them. Would mean a bloated plugin file though.

Yes, that's exactly what I'm trying to avoid. I've already gone that route actually, first posting about serializing the result of string.dump (after passing it through base64 encoding to handle the 0-chars), then making a script to act as a proxy between you and a plugin, getting a plugin variable and loadstring()'ing it. This is cleaner and more versatile, plus it conceivably allows for writing to the archive to change resources like a database.

*boggle*

I think I see where you guys are coming from with this. But how about this? First, let's look at how WoW implements plugins.

• They have an AddOns folder inside their installation directory.
  
• For each plugin there is a subfolder (not a file) (eg. Cartographer folder for the Cartographer plugin).
  
• Inside that folder are some standard files, in particular Cartographer.toc which is the "Table of Contents" file. That lists other files that are required.
  
• The plugin itself is a .lua file (Cartographer.lua in this case)
  
• I am not an expert, but somewhere in there are the dependencies (in other words, what other plugins also need to exist)
  
• Any required data is in the folder as well

Now this effectively gets around the mess of not knowing what belongs to what. They also have the idea of a "saved data" folder somewhere else. In their case they put different accounts into different directories, which is conceptually similar to the plugin state file which has the world id as part of the name.

I don't know about having everything in a zip file - it has to be unzipped anyway to use it, but the folder idea I quite like.

A while ago I did a "plugin installer" plugin which simply installed every plugin it could find in a directory. Effectively WoW does the same (other programs would be similar, eg. Photoshop). Rather than having to go through a "plugin install" process you simply unzip the plugin folder (for a specific plugin) into the plugins folder.

So, to summarize, what you could simply do is:

• Make a plugin per folder
• Inside that folder put the .lua file
• Also put any data (eg. images, sounds, databases)
• Somewhere (possibly the plugin itself) put dependencies

Now MUSHclient could scan all folders looking for plugins, build up a list, check all the dependencies are satisfied, and then start installing them (eg. the ones which others are dependent on, first).

All this could be tricky to get right, but your comments are welcome, even if you think my idea has serious flaws in it. ;)

I think all in all that's exactly what my initial idea was aiming for, so that's great. However I have to disagree with the sentiment of having to unzip an archive to use it. As I said, Java does this perfectly well with its JARs, and it supplies classes that make reading/writing compresed data entirely transparent. It is probably a little difficult to do this in C++ (since Java's already written it for you), so I'm fine with plain old directories. I think you hit the nail on the head with your Warcraft analogy.


Some problems come to mind, though.

1) At this point in time, disabling a MUSHclient plugin does not keep it disabled next time you open MUSHclient. This makes it pretty hard to run an auto-installer if everything's going to be added.

2) MUSHclient comes with many plugins already (and most that I have never used myself), so an auto-installer would also include all of those.

3) How does MUSHclient tell which directories contain a plugin? The benefit of using archives is that you'd have a standard file suffix like .MPA, although I see that archives also have their share of downsides.

4) The 'require' path. I desperately want this to be changed so that it checks a plugin's relative path first. If my plugin is in plugins\foo\bar\, I want require("baz") to look for plugins\foo\bar\baz.lua first. Otherwise this is just another bit of info tacked on to require; right now I have to use require(GetInfo(60) .. 'filename'), and this would be worse because the plugin's subdirectory name isn't necessarily fixed. It's throwing too many variables into the equation.

5) Back to the auto-installer. It would likely have no concept of installing certain plugins for only certain world files, and at that point you'd be better off adding it to the list on your own. I'd much prefer an auto-installer to just check the directory, and show the un-added plugins in a separate part of the Plugins dialog. That way I can select which ones I want to add for this world myself, and the plugins window would only display the ones that I've enabled myself. Did that make sense? I felt like I rambled a little there.

I must be missing something. What is hard about making a zip file with a file structure that when
unzipped at the MUSH directory creates a folder under plugins and extracts the required files into it?

Nothing. The original idea was to keep those files in the zip, i.e. not unzip them. It's possible to do that, it's just a fair bit harder for the code to handle compared to normal files. It just keeps related things together "under one roof", you might say.

Sounds good.