Because version numbers would be the way to know what the 'old information' is. Packages would in essence be pieces of software run on the Mudlet platform. That sort of scripting tends to receive frequent updates too. You'd want to be able to include versioning for the same reason you apply versioning to any other piece of software - keeping track of what's what without needing to compare code samples and rely on memory, something a basic user couldn't do to begin with.
Package management is a very significant part of what any modern client should do, really. When you get down to it, Mudlet is a scripting platform. Facilitating conflict-free, user-friendly external package usage (the vast majority of users won't be developers) should probably be a fairly high priority. I consider the lack of script sandboxing a fairly serious disadvantage already.
[please comment] package sharing solution
Re: feature request: package sharing solution
But why do you consider a lack of sandboxing a feature?
It's a design decision that's a feature... and no other Mush users have brought up its lack of Mudlet before.
It's a design decision that's a feature... and no other Mush users have brought up its lack of Mudlet before.
Re: feature request: package sharing solution
I didn't mean to derail, but here are my reasons.
The current approach depends on all plugin writers to 100% secure their code against spilling into the common environment. When somebody, somewhere, forgets to put 'local' in front of their 'health' variable, and starts making changes to the user's 'health' variable, the user ends up in a situation which few laymen will be capable of sorting out. This is all hinging on the hope that plugin writers will have read the appropriate post on these forums to begin with, that they aren't people who are just now learning Lua and are just writing things as they go along, with no concept of what a namespace is in the first place.
In my experience, programming paradigm is only collectively applied when it's harder to stray from it than when it's easier to break. In this case, you're going to have a good number of well-meaning developers for Mudlet packages that will not have properly secured their scripts. I've seen enough poorly written, but functionally useful plugins to be fairly confident this will be the case. This is, of course, on top of forcing an extra degree of care for Mudlet developers who are aware of the danger and need to double-check that none of their variables end up spilling out.
With no sandboxing, I as a user or as a developer, have to worry about any external script messing with the common namespace. If access to the common namespace needs to be explicit, I'll have the peace of mind of knowing that any scripts I install will not by sheer negligence be messing with anything in my main environment.
The current approach depends on all plugin writers to 100% secure their code against spilling into the common environment. When somebody, somewhere, forgets to put 'local' in front of their 'health' variable, and starts making changes to the user's 'health' variable, the user ends up in a situation which few laymen will be capable of sorting out. This is all hinging on the hope that plugin writers will have read the appropriate post on these forums to begin with, that they aren't people who are just now learning Lua and are just writing things as they go along, with no concept of what a namespace is in the first place.
In my experience, programming paradigm is only collectively applied when it's harder to stray from it than when it's easier to break. In this case, you're going to have a good number of well-meaning developers for Mudlet packages that will not have properly secured their scripts. I've seen enough poorly written, but functionally useful plugins to be fairly confident this will be the case. This is, of course, on top of forcing an extra degree of care for Mudlet developers who are aware of the danger and need to double-check that none of their variables end up spilling out.
With no sandboxing, I as a user or as a developer, have to worry about any external script messing with the common namespace. If access to the common namespace needs to be explicit, I'll have the peace of mind of knowing that any scripts I install will not by sheer negligence be messing with anything in my main environment.
Re: feature request: package sharing solution
Lua includes a module system that takes care of all of this however.
Sure, newbie coders will make mistakes, but it'll be fixed in due time. Meanwhile, no sandbox means just so much more freedom... esp. when you can make plugins interoperate. I wanted to make a plugin for Mush before that captured data into a globally-accessible data table for the user to use easily - no go, your plugin is sandboxed. People have come up with weird, weird ways around it - but frankly, not having the restriction to begin with is the proper solution there (I instead made plugins for cMud and Mudlet, and all was happy.)
Sure, newbie coders will make mistakes, but it'll be fixed in due time. Meanwhile, no sandbox means just so much more freedom... esp. when you can make plugins interoperate. I wanted to make a plugin for Mush before that captured data into a globally-accessible data table for the user to use easily - no go, your plugin is sandboxed. People have come up with weird, weird ways around it - but frankly, not having the restriction to begin with is the proper solution there (I instead made plugins for cMud and Mudlet, and all was happy.)
Re: feature request: package sharing solution
I'm not against access to the main namespace being easier. In MUSH's efforts to maintain a clean and safe environment, interoperability is indeed sacrificed to some extent. I'm against this being the default behavior, because many of the packages will be written by newbies. MUSH struggles, because plugins can be written in an array of languages, so obviously direct access to a plugin's environment isn't possible.
Making access to the shared namespace be the default behavior though is in my opinion asking for trouble. The larger potion of Mudlet's userbase won't be advanced Lua users. With that in mind, requiring only explicit access to the shared namespace is to my mind a very reasonable precaution.
Making access to the shared namespace be the default behavior though is in my opinion asking for trouble. The larger potion of Mudlet's userbase won't be advanced Lua users. With that in mind, requiring only explicit access to the shared namespace is to my mind a very reasonable precaution.
Re: feature request: package sharing solution
Yeah, but these people aren't plain stupid - it's rather easy to explain the concept of 'if you use this variable, someone else might be too and you'll be interfering'. While making interoperability work in a sandbox is just too much effort.
Just my opinion, and from the results so far, we haven't had issues with this.
Just my opinion, and from the results so far, we haven't had issues with this.
Re: feature request: package sharing solution
You make a nice argument, but if you look at the manual, esp. the section titled: Using Variables in Mudlet, with a special note that everything shares the same variables and functions.Hadoryu wrote:I'm not against access to the main namespace being easier. In MUSH's efforts to maintain a clean and safe environment, interoperability is indeed sacrificed to some extent. I'm against this being the default behavior, because many of the packages will be written by newbies. MUSH struggles, because plugins can be written in an array of languages, so obviously direct access to a plugin's environment isn't possible.
Making access to the shared namespace be the default behavior though is in my opinion asking for trouble. The larger potion of Mudlet's userbase won't be advanced Lua users. With that in mind, requiring only explicit access to the shared namespace is to my mind a very reasonable precaution.
Besides, anyone that's tried scripting before in a mud client, or shell, or just general programming for that matter, is aware that there is a certain learning curve that is associated with the new language. Plus, the more that you learn, the easier they all become.
So, if you are talking about a 10 year old, that wants to start scripting in mudlet simply because it "looks cool", then yeah, there could be problems expected, as that programmer has neither the experience, nor the patience yet to learn to think through the problem.
Now, if we are talking about a 40 year old masters of finance, that has a chip on his shoulder and has to know more than everybody, I'll take the 10 year old's issues created through innocence rather than the 40 year old's.
My point is that the shared namespace is damned handy to have. Regardless of whether it'll cause problems, well, it's not hard to open up your configuration file in a text editor (I live vim, btw), and search for the variable name that is causing your problems, and changing one piece of code or another.
The issues that you are bringing up, and seem to continue to keep saying is that in the shared namespace it is not possible to track down the issues; when, the fact is, it's not that hard if you take your programming problem solving skillz, and apply it to tracking down the cause of your problem.
I've found that the same skills necessary to write a script, are the same skills that are used to fix a computer, or a car, or to analyze an unknown substance with chemistry and science. The process is the same, so, if you want to blind yourself to that fact, then, jeez, the shared namespace must be KILLER!
So now, what was your point again?
Re: feature request: package sharing solution
I never made the case that people are stupid. They're going to be innocent mistakes, but they're going to happen. In MUSH, if a user of my plugin reports odd behavior, I know I only have to look into my own plugin's code to find the issue. In Mudlet I'll have no guarantees and I'll have no way to debug the user's entire environment.
My point, Knute, is still that your general user will not be capable of debugging plugins to start with, even if they can fix a car. Namespace contamination means that each Mudlet user's environment is unique, which allows a much greater array of problems on the basis of the individual platform. This also means that the developer needs access to the specific individual platform to debug such instances. If you write a plugin, then the still-learning user ends up addressing one of your variables (because they've taken a look and seen you do something similar), you're going to have a rather impossible time figuring out why it's misbehaving in this particular instance. A developer has access only to their own code.
I consider having to go an extra step to reach the global environment a very small sacrifice, comparatively. My concerns are my own though, and need not be taken into account. For me, personally, the lack of sandboxing will remain a distinct disadvantage as both developer and user, but that's obviously not going to be everybody else's opinion.
My point, Knute, is still that your general user will not be capable of debugging plugins to start with, even if they can fix a car. Namespace contamination means that each Mudlet user's environment is unique, which allows a much greater array of problems on the basis of the individual platform. This also means that the developer needs access to the specific individual platform to debug such instances. If you write a plugin, then the still-learning user ends up addressing one of your variables (because they've taken a look and seen you do something similar), you're going to have a rather impossible time figuring out why it's misbehaving in this particular instance. A developer has access only to their own code.
I consider having to go an extra step to reach the global environment a very small sacrifice, comparatively. My concerns are my own though, and need not be taken into account. For me, personally, the lack of sandboxing will remain a distinct disadvantage as both developer and user, but that's obviously not going to be everybody else's opinion.
Re: feature request: package sharing solution
To begin with, Mudlet's decision against a sandbox approach has been taken after long and fruitful discussions in the early days of Mudlet development. People that took part in this discussion had extensive experience in Mush and the other big clients in a multitude of MUDs. When you look at the number of Mush plugins that are actually being used widely, you'll be amazed how small this number really is. In the end of the day there are simply very few general purpose problems that can be covered by plugins because the diversity of MUDs and their respective needs is too large. That was the main reason why Ixokai stopped the development of his framework Mudlet Crucible. When he switched from IRE type of MUDs to Aardwolf, he basically had to start from scratch because the differences between these type of MUDs were too big and there was basically no code that could be reused, thus making his general MUD independent framework idea unrealistic.
When you look at the biggest Mush system I know of (Treant for Lusternia) you'll see that it is *NOT* built as plugins because the plugin approach has too many disadvantages.
Plugins are conceptually autarchic, self-contained modules that add certain functionality to the application. Conceptually, there no data sharing, functional sharing between plugins, content or function access from outside and most importantly, no plugin loading sequence i. e. plugins cannot depend on other plugins.
Consequently, in a MUD environment the usefulness of plugins is basically non existent other than adding new *client* features. Using plugins for user trigger systems leads to a quagmire of problems as soon as users start to work on using some of your plugin functionality in their own scripts or want data access to your plugin. Then somebody else develops another cool trigger set system as a plugin B that requires another plugin C which, in turn, requires plugin D to work. This is where the plugin nighmare starts.
In Mudlet you have none of the above problems. The only theoretical problem is a potential variable collision. The manual advises plugin authors to prefix their global variables accordingly to make sure that there is no such *unwanted* collision. Please note that people will gladly use your variables all over the place in their own scripts in order to add their own ideas, preferences, new features etc.. Mudlet's universal namespace makes this very easy. This is a 2 edged sword type of problem. If you don't want people to mess with your scripts then the plugin approach would be certainly more appropriate, but this would strongly decrease the usefulness of your plugin for most people as it's obvious that people like to tinker with your scripts and adapt them to their own needs and liking.
Adding a sandbox plugin type of feature to Mudlet would be a fair bit of work and few people would use this feature in my opinion. But if somebody wants to write a patch, he's welcome to contribute.
I'm currently working on a real package system that allows for package installation and deinstallation. Any good thoughts on this area are warmly welcomed.
When you look at the biggest Mush system I know of (Treant for Lusternia) you'll see that it is *NOT* built as plugins because the plugin approach has too many disadvantages.
Plugins are conceptually autarchic, self-contained modules that add certain functionality to the application. Conceptually, there no data sharing, functional sharing between plugins, content or function access from outside and most importantly, no plugin loading sequence i. e. plugins cannot depend on other plugins.
Consequently, in a MUD environment the usefulness of plugins is basically non existent other than adding new *client* features. Using plugins for user trigger systems leads to a quagmire of problems as soon as users start to work on using some of your plugin functionality in their own scripts or want data access to your plugin. Then somebody else develops another cool trigger set system as a plugin B that requires another plugin C which, in turn, requires plugin D to work. This is where the plugin nighmare starts.
In Mudlet you have none of the above problems. The only theoretical problem is a potential variable collision. The manual advises plugin authors to prefix their global variables accordingly to make sure that there is no such *unwanted* collision. Please note that people will gladly use your variables all over the place in their own scripts in order to add their own ideas, preferences, new features etc.. Mudlet's universal namespace makes this very easy. This is a 2 edged sword type of problem. If you don't want people to mess with your scripts then the plugin approach would be certainly more appropriate, but this would strongly decrease the usefulness of your plugin for most people as it's obvious that people like to tinker with your scripts and adapt them to their own needs and liking.
Adding a sandbox plugin type of feature to Mudlet would be a fair bit of work and few people would use this feature in my opinion. But if somebody wants to write a patch, he's welcome to contribute.
I'm currently working on a real package system that allows for package installation and deinstallation. Any good thoughts on this area are warmly welcomed.
Re: feature request: package sharing solution
I'm afraid I have to disagree with you based on experience.
I've been on MUSH for 6 years. My very sizable, very first system is written as a plugin. Every piece of script that is passed around for MUSH is in plugin form or is a hack-job. Nobody wants their world file polluted. This has been one of the biggest advantages MUSH has had over other clients, to my mind - I never have to worry about the client itself ever writing to my code and possibly destroying it, like Z/CMud continues to do to this day. I never have to worry about an outside plugin throwing crap into my world file or somehow tangling with my other plugins in unexpected ways. I can cleanly add/remove/reinstall any plugin from a neat menu and know that everything is separate. Treant may have made his choice for whatever reason, but MUSH's world file is essentially a plugin itself, simply one which can be edited through the client's interfaces. No offense to him, but I'd have to call this a case of negligence, because that approach is actually much more inconvenient for the user.
I have about five interlinked plugins, some handling my offence, some handling coloring/gagging, some handling my elaborate prompt substitution and a separated autosipper. The notion that plugins can't cooperate is completely false, function calls can be made from plugin to plugin and plugins can detect other plugins being installed/disabled/uninstalled et cetera. The one thing you cannot do is invade another plugin's namespace, but the reasons for this are obvious - plugins can be written in different languages and run on different engines. I have Python plugins interacting with Lua plugins.
The reason there is no great deal of MUSH scripts comes down to client popularity, not due to the plugin management system. MUSH is a strict client with very poor visual support, it has a nasty learning curve and can't entice new users with shiny gauges or animations. MUSH is not difficult to script for any more so than Mudlet and certainly not ZMud, but it is an elaborate platform and as such takes a while to get to know. Mudlet is on its way to becoming bigger than both (hopefully), but if anything that makes this decision all the more important as the number of packages and package writers goes up.
The issue with the current approach is that many people will simply not get the memo about prefixing their variables and functions and many others yet will simply make mistakes, such as not declaring as local or omitting the prefix in a few cases. As the number of packages grows, so does the probability of collisions. I've seen enough beginner scripts to be pretty sure you're going to have many people who won't be following the prefix paradigm.
I'm not saying Mudlet needs to adopt MUSH's "don't look, don't touch" approach to plugins. Being able to easily access the global namespace can be very convenient and it's worth keeping that option open. What I see as a problem is the global namespace being the default for every package as well as the main script, when considering that a very large number of the users and developers will have only the most basic understanding of Lua and programming in general.
I don't know how Mudlet implements it's script/package loading and I don't know how hard it would be to create this environment separation, all I can do in good faith is caution that this will very likely cause problems in the future, proportionally to the number of new users and developers. Maintaining good programming practice can be troublesome within a corporate environment. In an unsupervised and unfiltered environment, I consider it largely a lost cause.
I've been on MUSH for 6 years. My very sizable, very first system is written as a plugin. Every piece of script that is passed around for MUSH is in plugin form or is a hack-job. Nobody wants their world file polluted. This has been one of the biggest advantages MUSH has had over other clients, to my mind - I never have to worry about the client itself ever writing to my code and possibly destroying it, like Z/CMud continues to do to this day. I never have to worry about an outside plugin throwing crap into my world file or somehow tangling with my other plugins in unexpected ways. I can cleanly add/remove/reinstall any plugin from a neat menu and know that everything is separate. Treant may have made his choice for whatever reason, but MUSH's world file is essentially a plugin itself, simply one which can be edited through the client's interfaces. No offense to him, but I'd have to call this a case of negligence, because that approach is actually much more inconvenient for the user.
I have about five interlinked plugins, some handling my offence, some handling coloring/gagging, some handling my elaborate prompt substitution and a separated autosipper. The notion that plugins can't cooperate is completely false, function calls can be made from plugin to plugin and plugins can detect other plugins being installed/disabled/uninstalled et cetera. The one thing you cannot do is invade another plugin's namespace, but the reasons for this are obvious - plugins can be written in different languages and run on different engines. I have Python plugins interacting with Lua plugins.
The reason there is no great deal of MUSH scripts comes down to client popularity, not due to the plugin management system. MUSH is a strict client with very poor visual support, it has a nasty learning curve and can't entice new users with shiny gauges or animations. MUSH is not difficult to script for any more so than Mudlet and certainly not ZMud, but it is an elaborate platform and as such takes a while to get to know. Mudlet is on its way to becoming bigger than both (hopefully), but if anything that makes this decision all the more important as the number of packages and package writers goes up.
The issue with the current approach is that many people will simply not get the memo about prefixing their variables and functions and many others yet will simply make mistakes, such as not declaring as local or omitting the prefix in a few cases. As the number of packages grows, so does the probability of collisions. I've seen enough beginner scripts to be pretty sure you're going to have many people who won't be following the prefix paradigm.
I'm not saying Mudlet needs to adopt MUSH's "don't look, don't touch" approach to plugins. Being able to easily access the global namespace can be very convenient and it's worth keeping that option open. What I see as a problem is the global namespace being the default for every package as well as the main script, when considering that a very large number of the users and developers will have only the most basic understanding of Lua and programming in general.
I don't know how Mudlet implements it's script/package loading and I don't know how hard it would be to create this environment separation, all I can do in good faith is caution that this will very likely cause problems in the future, proportionally to the number of new users and developers. Maintaining good programming practice can be troublesome within a corporate environment. In an unsupervised and unfiltered environment, I consider it largely a lost cause.