Pushing down byte[] into XmlAdapter?
Issue #38
wontfix
I noticed that AvatarManager is natively dealin with byte[], which is a bit awkward, as it mixes up the logic behind avatars (level 7) with the technology needed to hold the bits (level 6). I wonder whether it might make more sense to push down the transformation from java.awt.Image to byte[] and vice versa into an XmlAdapter<Image, byte[]> to have clear separation of concerns?
Comments (3)
-
repo owner -
repo owner In this case the publisher and receive both use Java's ImageIO, so the byte[] is probably the same. But I had the case when downloading an image, converting it to Image and then converting it back to byte[]. The original byte[] differed from the converted one, so the hash didn't match anymore.
-
repo owner - changed status to wontfix
As discussed, this is a bad idea.
- Log in to comment
This is not possible because we have to have the byte[] available for building the hash and compare it with the provided hash. If we have an Image instead and use ImagIO to create a byte[] again (for hash comparison), it's most likely not the same byte[] as originally provided and therefore messes up the logic, e.g. an avatar would be downloaded again, althought it's in the cache.