Switch from .xml to a better file format

Feature Requests Snap! Feature Requests
1

I propose a better file format for Snap! as the existing XML system can use an enormous amount of data, even more than scratch’s .sb3. I don’t have any idea for a name but someone could propose it here. Maybe we could use something like .ypr2 or .snap.
It is essentially a zip file containing

  • Each costume, sound, and background will be SHA256 hashed, and then it will be under the filename [hash].[ext] instead of how the existing system uses inline URLs.
  • project.xml will basically be the existing xml file but without the massive base64 stuff.
2

Prehaps even encode the project as binary data to be even more compact..

I could maybe try to code up a prototype, I am craving some Snap! JS coding…

3

Jens is unlikely to accept unsolicited code for something as central as saving and loading projects.

4

From what I understand, Scratch isn’t very efficient when it comes to saving blocks. However, Snap goes and encodes images and sounds in Base64, which means that once you start adding those to a project the size can balloon.

5

I like XML to be honest, because of its simplicity.

6

?!
Absolutely not! This will make loading speeds terribly slow, especially on already slow devices

7

Not really.. It’ll only hash on save, to export the files, and the XML file will simply contain the hash. And either way, we could use MD5 (like Scratch!) for that bit of extra speed. And besides, the media files shouldn’t be that big, and hashing files isn’t that slow.

8

Never mind about speed; hashing is a one-way algorithm.

9

Exactly. To recover it, you would have to generate, hash, and compare every single possible combination of characters.

10

I’m pretty sure he meant that referencing an image would be SHA256 encoded. You would store the image in the file, but when referencing it, you would provide the hash.

11

But.. why?

12

probably because that’s what scratch’s .sb3 files store images

13

efficiency

14

In what way would hashing an image to make sure the hash matches the hash in the save be more efficient than.. not doing that?

15

What would be your alternative to indexing without hashing?

16

What correlation does hashing have with indexing?

17

Referencing = Indexing

18

That’s not even what it’ll be.. The images are hashed, and saved with that filename, and project.xml contains those names. Actually, to be honest, using UUIDs would be faster to save, but either way (UUIDs or hashing) the loading process just loads the file with the name in project.xml.

19

I think the purpose of hashing is to avoid saving the same image twice, e.g., if two sprites have it in their wardrobes.

20

Oh, okay. Hashing the image and then using it as it’s index doesn’t make sense. This makes it so that you cannot have duplicate costumes. A UUID or a NONCE would be so much better.