Hey everyone,
as you might know, I am planning on porting ChestShop to Sponge. However, since the API is changing diametrically, it will be hard for me to retain the backwards compatibility. This is why I have to ask you - should I rather concentrate on making ChestShop a proper successor to its Bukkit predecessor that will not accept the signs from previous version, or should I retain the backwards compatibility using “hacks” and limit myself from unleashing full Sponge potential?
Why would the syntax for the signs need to change, in order to “unlock Sponge’s potential”?
How you parse the sign’s content is entirely inconsequential to what API/Implementation you’re using.
I think you should do what is best for the plugin. The only thing that should hold a server admin back from changing, is loosing the save data. If you are also concerned about this, you could always add a converter that checks for old style data in the initilization process, then convert it.
Also, I’d be interested in helping with the development.
I’d go with a fresh start and add a tool to convert the old data later.
zml somewhat did this with PEX too and it works great!
Oh and what @FerusGrim said!
It is, however ChestShop does not save the information about shops in any database - thus, it relies on the sign to read the information. Data like item information, etc. that CAN be used with Bukkit probably will not work with Sponge (different names). The same goes for UUIDs - ChestShop relied on usernames for a long time and since they were replaced with UUIDs, I had to implement a UUID <-> username database - again, this is a “hacky” way of retaining the compatibility.
If I were not restricted to retaining the backwards compatibility, I would save all new shops to a database and make the signs only display the necessary information. This means that any changes similar to the username -> UUID one will be easy to accommodate for. Additionally, features like GUI for the shops, etc. will also be trivial to add.
@Tzk, @mmonkey - as I have said above, ChestShop saves the data on signs. There will be no possibility of converting the old sign data unless I scan all the signs. As for the help with development - I will be doing all the work on GitHub, however I first need to set a foundation for the rest of the plugin.
If I were in your shoes I would write it for sponge first, then maybe have a compatibility plugin to convert signs from the old to the new.
I’d also recommend against a database if possible.
The reason why people preferred ChestShop over alternatives were because it didn’t use a database. Maybe look into custom data manipulators to attach custom data to either the sign or the chest once it’s implemented in sponge.
I’ve been using Chestshop for many years, it’s always been reliable, as has the charming and dedicated @Acrobot himself. I would be delighted to see a new version optimised for Sponge!
I concur that the absence of a Database is one of the attractions of Chestshop over alternatives, in much the same way that Lockette and LWC differ. One is driven entirely by what’s on signs, the other by data invisible to the player. I’m not sure that the impact of a DB is all that significant, or any better or worse than having to scan for surrounding signs on interact. Is there any way to tell what would be better, from a server-timings perspective?
For forward compatibility with Sponge, and to get the best possible use of the new API, I would wholly support a completely new system for ChestShop, DB-based or otherwise. There is only so much information you can put on signs, and I’d hate to see that work as a limitation to what can be achieved by a clever plugin dev. A long-winded converter that searches for and indexes the shops in a map might be a way to achieve conversion, though it seems heavy-handed… but it only needs to run once, much like the old Anvil map-save conversion processes did.
I would recommend aiming for smooth, robust code with the new infrastructure system, trying to take advantage of it fully and go with it from a now-forwards stand.
Like most server owners, I am prepared to accept that I will need to reset everything on my server for sponge, due to the impossibility of all of my core, infrastructural plugins being migrated, and missing something valuable that i need to switch to a replacement program anyways - which even on a bukkit server, if a big enough infrastructure to my server, would warrent resetting.
But being prepared and hoping not to have to at the same time…
Since a migration to sponge is a big undertaing for any server owner - and though some folks around here would like to say that in time "ah, you just swap this and that file for that file, and you’re up in 5 minutes; it is at least a big enough change compared to replacing a craftbukkit.1.sumnumber.number file with craftbukkit.1.sumbiggernumber.othernumber file and has to make even the server owners who insist on running servers with 15 red-colored plugins in their list, and errors spammed to log each time they interact with a block take pause for a moment and realise … something is kinda big and different here.
But as big as it is to make a trnaasition … its also done once, then, its over.
The owners who cant be bothered with researching, reading, trying to figure out how to make tough things work are going to just wipe anyways, the ones who have serious amount of investment and desire to keep the same maps and such are going to look into whatever it takes to preserve them, and will be willing to invest in one-time special utilities to convert data from one form to another in order to bridge it.
But it should be the responsibility of the server owner to perform a one-time bridging step to transition existing map data into a new state that a plugin can use, if that plugin has a much better way of handing data now as you will. Once that transition is done, there is no need to look back.
So I would have to imagine that a plugin will be smoother, more reliable, easier to program and debug for you if you can focus on now-foward for the regular use, rather than incoroprating backwards compatibility work into it (almost writing two plugins in one). But at the same time, making a separate, smaller, cleaner, faster, streamlined single-run converter utility for server owners to run first as a separate one-use plugin that is not a part of a released day-to-day use plugin in order to capture that information from the map and transmogrify the map / plugin data to make it forward-usable … if doable … would be fantastic.
But it shoudl be a stand-alone utitlity, for the significance of the one-timeness of a GRAND system overhaul - its not just you upgrading your plugin and trying to backsupport your plugin – upgrading to that version of your plugin already has the server owner at a point where the acknowledgement is that a true, data-preserving upgrade across the entire spectrum of his plugins is no small feat, a job that is going to require a LOT of work across a spectrum of things.
So “backwards compatbilty” for the plugin …no, trim that fat in order to take advantage of every thing you can in the new system. One time migration of the system for your plugin, yes please.
Even if it takes a utility hours to convert the map for your system, this is an instance where that is the cost to pay for the decisoin and investment of the owner. No one in such a situation is going to scream about how their server is offline for 2 hours to the equivalent of a heart, brain, lungs, kidneys, liver and intestine transplant. Be frustrated with multiple systems that are taking an hour to one-time run each but knowing that in the future, all their plugins are optimized and streamlined for the server operation, yes, that may happen. But the more important map is to keep (years old for some) what is an hour? As long as I knew the utilility was not crashed, i’d wait a day for a util to convert all my maps as being part of the process, to keep 2 year old maps.
Well said.<oh look, the char limit hak, how did thay get in here>
Another possibility: when an “old-style” sign is used for the first time, parse it and add it to the database. Is there a reason that wouldn’t work?