Design specification for "SB3"

[thisandagain]

Serialization Requirements

• Serialization format must represent the program
• Serialization format must represent the program's current state (backgrounds, variables / lists, sprites, etc.)
• Serialization format must be able to be packaged along side assets (sounds, images, etc.)
• Serialization format should use space efficiently
  • Compression
  • Duplication (see "lists" issue in SB2)
  • Representation (balance with "readability"?)
• Serialization format should be able to be strongly validated (JSON schema)

Package Requirements

• Package format must include all information needed to replicate and execute the program without an internet connection. Possible exceptions:
  • Cloud Variables
  • Extensions
• Package format should use space efficiently

Considerations / Questions

• How do we represent Scratch extensions (e.g. SB2)?
• How do we ensure that the addition of new blocks / functionality in the future can be easily accommodated (flexibility)?
• How do we accommodate SB3 files in our projects / asset infrastructure?
• How do we handle issues of backwards compatibility?
  • SB2 -> SB3 conversion
  • SB3 files should throw a friendly error message to Scratch < 3.0 clients

Related

• Project loaders: SB/1.4 #128
• Project loaders: SB2 files #127
• https://github.com/llk/scratch-parser

[BookOwl]

What's the state of https://github.com/llk/scratch-parser? Is it anywhere close to useable?

[thisandagain]

@BookOwl It's usable for SB2 projects. In fact, we use it for research quite a bit.

[BookOwl]

Can you please make it public? I would really like to mess around with it.

[thisandagain]

@BookOwl All set. Very much still a work-in-progress. Any contributions would be most welcome!

[BookOwl]

Wow, thank you! :D

[PullJosh]

I would love to see the ability to use Scratch Extensions offline as well. In terms of keeping file size small, it makes sense to host most extensions online, but if users want to explicitly choose to include extension files within their scratch projects, that would be a neat feature to have available.

[birdoftheday]

Not sure if this is related, but one thing I would very much appreciate is the introduction of 'libraries' or 'packages' or something similar. It's very tedious to copy and paste custom blocks from one project to another and a feature of at least being able to import scripts from another project would be nice.

[ed-cooper]

@birdoftheday Nice idea, but maybe better to place it in the suggestions forum or a separate issue

@thisandagain Also, wouldn't the "username" block also be an exception for using the project without internet? (not that it really affects the file design specification anyway)

[tmickel]

Re: "Serialization format should use space efficiently" - are we aiming for efficient usage post-compression or pre-compression? For example, the duplication issue shouldn't matter if we're aiming for post-compression, and neither should the verbosity of XML. But if we're aiming for pre-compression efficiency, clearly it would :)

[towerofnix]

Nice idea, but maybe better to place it in the suggestions forum or a separate issue

@chooper100 a tad meta, but it would probably have something to do with the storage of SB3 projects :P

EDIT: Though it is probably fit for another idea, to keep discussion organized.

[as-com]

The serialization format should also be efficient to parse, so large
projects would not crash the player or take a very long time to load.

XML is certainly not a fast nor efficient serialization format.

On Mon, Sep 19, 2016 at 1:21 PM Tim Mickel notifications@github.com wrote:

Re: "Serialization format should use space efficiently" - are we aiming
for efficient usage post-compression or pre-compression? For example, the
duplication issue shouldn't matter if we're aiming for post-compression,
and neither should the verbosity of XML. But if we're aiming for
pre-compression efficiency, clearly it would :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#194 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADpIaYm1znjRzeLmTdj2SHroiuayOTIVks5qrsSfgaJpZM4KAfCr
.