Nick Gammon said: Maybe other people love it, I'm just answering your query about having comments.
Thanks!
Nick Gammon said: Well you have a .zip file, which to someone suspicious is immediately a red flag
Can you clarify? I see .zip files all the time; even WoW addons are distributed as .zip archives.
Nick Gammon said: and then inside you have four files and two directories, to achieve what I have done in a forum posting.
Brevity is a good point. The extra scaffolding is to keep things grouped together, but if you can fit the whole plugin in one file, it might not be worth it.
Nick Gammon said: Now admittedly you supply the luacom.dll, but if you have 10 plugins that need LuaCom, then you supply it ten times. This seems to me to break the idea of centralizing stuff you only need once.
That's another good point. Maybe it would be a good idea to have a shared_libs folder within the .zip file, outside the plugin folder itself. Then when it's unzipped in the plugins folder, if there's already an existing shared_libs folder it would be merged. It just looks uglier, it's easier for things to clash, and the plugin folders aren't single units anymore. Pros and cons...
Nick Gammon said: Just personally I find the structure you use confusing. You start with a generic plugin.xml file (and so in the plugin list you see lots of plugin.xml files, so I wonder which is which), but that has an alias in it and then loads in plugger.xml.
Usually I put aliases/triggers/other XML objects in the reflexes/ directory, and include them from the plugin.xml (which I call the manifest). It's true that maybe it should be named after the plugin instead, but I opted for something generic originally.
Nick Gammon said: Then inside plugger.xml (which is inside another folder) I open that and find it does some fairly complex stuff with paths and things, but I guess it eventually finds main.lua in yet another folder.
Plugger just sets things up to adjust to the folder structure. There's a require("scripts.main") at the end which uses the adjusted paths to load and run main.lua.
Nick Gammon said: Finally in main.lua is the "meat" of the plugin which actually does the text-to-speech stuff.
I basically just copied from the original plugin's <script> tag and moved it into main.lua, converted it to XML, and put it into a skeleton plugin structure.
Nick Gammon said: Now I have had to open three files, in different folders, to even find how you implemented the text-to-speech. And they have generic names (plugger.xml, plugin.xml, main.lua).
Imagine for a moment how confusing the MUSHclient source would be if every file was called main.cpp, and the "real" meaning of the file was in the name of the directory two levels up.
I feel that way at times with CMUSHclientDoc, but that's beside the point. :) I agree that maybe the plugin XML should be named after the plugin itself, but 'main' is a rather common/standard entry point name. If you know that main.lua is where the plugin effectively "begins", you don't have to look for anything else.
Nick Gammon said: On this site I try to teach how to do things, and in my example plugin above you see, in one place, the whole thing. The alias, the plugin script, everything. And it is, after all, only 145 lines long.
Your structure breaks everything up, so I have to mentally reassemble it. One file has aliases, another has the script, another loads the first two. It's just confusing to me.
Excellent point. Generally though, you never have to concern yourself with Plugger, it's more of a mini-framework. The plugin.xml file, in my mind, shouldn't even have any actual aliases or code or anything, so I really should have put that in reflexes/aliases.xml or something and <include>d it. Plugin.xml is by and large just for metadata, and as I said before, I consider it the "manifest".
scripts/main.lua is where the work actually begins, and if all you want to do is figure out how something works, that's generally where you want to go first.
As an aside, I usually have a readme.txt at the same level as plugin.xml with directions, troubleshooting, and requirements. I just threw this one together, which is why it's so sloppy. |