saving projects from extensions

Feature Requests Community Site Feature Requests
1

I am sorry if this is "complaining about an extra". If it is, you may ignore it.

Main

Snap is powerful, much more powerful than scratch. In fact, it is exactly as powerful as JS, (can do js and is in js) but all functions other than APIs can be done in snap, usually without too much technical knowledge. Many snap users (about 2/3 I would guess) sometimes make libraries. About 1/2 of those make libraries using JS. About 1/2 of those libraries (made by 1/4 of the people) should have been a snap extension. But they are not. (actual snap extensions not counted)

This is a problem that scratch had. In snap it is probably worse because of JS, but scratch did have a similar problem. The problem is that it is easy to save projects with libraries that are base projects, but hard to save modified projects.

I am suggesting a log in with snap option that can be used in snap extensions to save projects to the main snap cloud. When setting this up, there should not be any way to share extended projects, so as to avoid confusion about the system. Enabling shared extended projects will probably not be difficult for the server, but it may be a bit of confusion that is too much. In any case, beta testing where most users do not see it is good. The option would allow extended clients to save and load projects from the main snap server. If any client tries to load any project that is not either a project of its type or from base snap, then it will give a warning. If it fails to understand some part of the XML, then it will have an option to cancel load or to try to understand what there is. If there is an error, then it will also dosplay a warning before saving.

Pros:

  • things that should be extensions are (at least more often)
  • less copies of a library (instead of every project using the library having a copy, the extension is hosted on gh pages etc.)

Cons:

  • higher server traffic in not the main purpose of snap
  • possible programmatic use (maybe fix by reviewing extensions first)

Sharing

Pros:

  • full use of snap with extensions

Cons:

  • worse server traffic error
  • no advantage to running your own server (possible extreme load from people not making custom servers anymore)
2

I'm not 100% sure I understand what you're proposing. I get the bottom line, which is that you want extensions to be able to save into the Snap! cloud. But I'm not sure what problem that solves, for you. I think there are reasons to want a closer integration of approved extensions, mainly so that the extension can stay up to date with the core Snap!. That would involve a git-like merge of two branches when we update Snap!. I think we'd even go a step further than you, by making user projects from an extension visible to all, and arranging to load the right extension when you double-click a project.

But I don't understand why you think libraries are a problem. Loading the library with the project does use extra cloud space, but it avoids software rot, which is what happens when a library changes its API in some way that's not compatible with older programs using it.

I guess part of the problem is that we use the word "extension" differently from how Scratch uses it. Their extensions are much like our libraries: an add-on collection of blocks that work with the vanilla Scratch evaluator and UI. To us, an extension is a major rewriting of Snap! itself, done by someone other than us, and distributed on a web site they maintain. Are you thinking about Scratch-style extensions? If so, I don't understand how we aren't already providing that. When you say that half the people make libraries, and half those libraries "should be extensions," I don't know what that entails.

To me the biggest library problem is about software rot. 6.0 broke the getter/setter (Eisenbergification) library a little bit. I fixed it, not quite in time for the initial 6.0 release, but that's the sort of problem that I think about for libraries and/or extensions (either kind). Most Snap! updates are not nearly as pervasive as 6.0, which changed everything. Usually the libraries aren't so fragile. But 6.0 caused more than one library problem. (Bignums are still broken, @djdolphin.) Come up with a system to stay on top of that sort of thing and I'll love it!

I guess the question is which kind of software rot is more common, a change to a library that breaks projects that use it, or a change to Snap! itself that breaks a library. The shift to 6.0 presumably broke every project that was built before 6.0 using bignums or Eisenbergification. That's a disaster, I guess, because the projects are still published, and their authors might have no idea why their project no longer works. So, dynamically loading libraries would have been a win this time.

But, yeah, we should improve the situation with libraries in many ways, starting with the easy one, which is that we need a hierarchical menu, putting libraries in categories, because there are too many of them now.

3

2 posts were split to a new topic: Undoing libraries that modify Snap! when a new project loaded

4

With regard to libraries getting broken, going forward I think it would be a good idea to give libraries a version number. Mark each library block with the library name and version, as well as a flag that's set if the user modifies the block definitions.

If old library blocks are detected, give the user a prompt like:
This project uses an old version of LIBRARY. Update?
or
This project uses an old, modified version of LIBRARY. Update?

For existing libraries which are broken in old projects, maybe detect them by block name or by a hash of the block definition, and do the same thing.

5

Mose librarites are good. The problem is ones like bignums and my hashtables library that add data types or replace primative blocks. These should be an extension.

I meant a fork of GitHub - jmoenig/Snap: a visual programming language inspired by Scratch, including both complete rewrites and also simpler things that add datatypes or edit primitives. Snap! Build Your Own Blocks 6.0.1 - dev - may not t, but most things do.

Another advantage of using forks is that you can have forks of forks, like json is a fork of hashtables is a fork of snap.

6

If it helps, I found this in the console:

Refused to execute script from 'Redirecting to Snap!' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

7

Oh. But I (I especially!) don't want to start a competing Snap!-with-Scheme-numeric-tower. I want the Scheme numeric tower in regular Snap!, and I want it to still work when a new Snap! version comes out. Unlike Jens, I don't view overwriting the JS arithmetic functions with mathematically correct ones as a hostile act. Forks would be for, e.g., a version of Snap! based on DOM rather than Morphic.

In a perfect world, the Colors library would overwrite SET PEN () TO () with its version! But that's less crucial than getting arithmetic right. I'd like to be able to take any old Snap! project and have it run with Scheme numbers. ("Any old" as one compound word, not implying old projects.)

In a perfect world, every programming language would provide Scheme numbers and no other kind of arithmetic. People have died because of integer overflows. It's the 21st Century.

</rant>