The missing capability to properly serialize and deserialize stuff like item stacks has been one of the greatest flaws of bukkit, especially when using MCPC/Cauldron. So when I saw the approach sponge is taking on this topic, I got really excited. Apparently everything like block states, item stacks etc implements DataSerializable so it can be stored in data containers and deserialized later, without loosing mod-specific data.
However, after taking a look at the way this is being implemented I’m not so excited any more. Ideally, the DataContainer for a DataSerializable would be created from it’s NBT representation. Instead, every data serialization/deserialization process is beeing implemented manually. Apart from the fact that this isn’t very efficient developement-wise, it’s also absolutely not mod compatible, as only known DataManipulators get serialized.
Yes, this system can be extended. Yes, the mod authors could implement their own DataManipulators. But will they? Most certainly not.
It would be really sad if sponge would make the same mistake here bukkit did before.
The Data system is meant for maximal compatibility throughout the API. All DataManipulators are supposed to be represented in any DataContainer you retrieve from any DataHolder or ImmutableDataHolder. Of course, when it comes to mods adding their own data, we simply can not be naive enough to expect mod authors to provide a compatibility module for hooking into our Data system. What we do instead, is still provide the “raw” data so to speak to include ALL data, regardless whether it’s vanilla or mod data. This is purely an implementation detail that we can’t avoid, but it should be known that when you call toContainer() on an Entity, TileEntity, BlockState, or ItemStack, you should very well be able to have a DataContainer that has both the Data API representation of data, AND a copy of the implementation DataContainer converted NBT.
It will always be recommended to deal with Data API itself, but if a mod doesn’t have a compatibility library for SpongeAPI, of course, reading and manipulating the raw DataContainer is the alternative, as you’d have all the string to object values related to the DataHolder.
Make no mistake, we WANT plugins to be able to deal with mods, but ultimately, we know that most mods will not give us the time of day to write a compatibility library to interface with the Data API system, let alone with our events.