hmmmm
you don't know that.
i dont
That why I said
Jeez, you guys, I am so tempted to establish a rule that every day I wake up to a flag war we turn the whole forum off for a day.
Luckily for you, collective punishment is officially (UN) a Crime Against Humanity.
@programmer_user, @helicoptur: coder2195snap has the habit of overstating his case, like a lot of y'all (so tempting to name names here (I don't mean either of you two)) but he's trying to be helpful. Compressing projects on the cloud is a good idea, although I have the vague impression that virtual computers (such as the Snap! cloud) are already stored compressed. But we are talking about moving to storing media separate from project code, so that we don't need a zillion copies of alonzo.png on the server. That would eliminate the need to include code and media in one zip archive.
@coder2195snap: Jens has repeatedly explained that the reason for using Morphic, our own widget manager, is that it supports lively code (the ability to modify a script while it's running and see the result immediately) much better than DOM elements would. I think it would be an interesting research project to find out how much our users actually do that. We know that there's a big cost to that choice; we have had to reinvent things like text entry and (not done yet) support for screenreaders. But we're unlikely to change that, which would mean a(nother) complete rewrite of Snap!.
As it is, Jens did do a major rewrite recently to use a separate canvas for each widget rather than just one big canvas for the whole window. That led to a significant speedup.
wdym by that
And how about use JSON instead of XML
Well I'm not overstating I'm suggesting
Plus I think JSON+ZIP is a better way of compressing than XML
JSON doesn't help with compression.
SOME STUFF ABOUT JSON VS XML
FIRST THING:
JSON is faster because it is designed specifically for data interchange. JSON encoding is terse, which requires less bytes for transit. JSON parsers are less complex, which requires less processing time and memory overhead. XML is slower, because it is designed for a lot more than just data interchange.
Don't cha think if would be better if XML projects moved over to JSON?
(Emphasis added)
Really it's only the JSZip one that's offensive.
That's an apples and oranges comparison. Zip is about compression; JSON is about preserving structure when serializing. You'd have to compare JSON with XML, or JSON+Zip with XML+Zip.
And we do a lot more than data interchange. Deserialization is like writing a compiler for a special-purpose language. Most of those articles Google found for you are thinking about a simple database with fixed-format records, so size is the only real criterion.
Of course JSON would be smaller, only by virtue of using brackets instead of end tags: [TAG: foo bar bletch] instead of <TAG>foo bar bletch</TAG>. One possible virtue of the XML approach is that it makes it easier to fix file corruption because of the redundancy; a missing end tag will cause a mismatch when the next end tag is seen, whereas a missing ] could be anywhere.
Having said all that, we've gone back and forth on how to do serialization over the years. I think I'm remembering correctly that in the BYOB days we rewrote the serializer and deserializer at least once to switch formats. So your suggestion isn't stupid; there would indeed be some real advantages to JSON. But there are also real advantages to XML, so it's not an obvious choice.
But why are assets included in xml
Why can’t they be a separate file in a zip?
Yes, absolutely. If you look back at my post in a different thread about which you said "prob never," you'll see that it's about separating media from code so that we only need one copy of each costume or sound on the server.
I think y'all don't get that we're all frantically busy putting out fires. Right now, as discussed in another thread, the biggest fire we're working on is that school districts won't let teachers use Snap! unless we sign contracts making a bunch of promises about student privacy and about data security. So, yeah, saving some server space, while also important, is on the back burner.
Ooof 
Hmmm but what is so unprivate about puts assets on an seperate area inside zip file
What? No. I'm not trying to make a connection between privacy and your suggestion, except the connection that we can't do everything at once.
Could you explain what you mean
Did you mean that you have too many contracts to sign so you cant change snap zip xml thingy??
he is saying that privacy has nothing to do with it. and that they are also busy doing other stuff for snap.
No, it's not the actual signing that takes time. It's that the contracts they want us to sign involve us guaranteeing the privacy and security of student data, and we can't make that guarantee given the current way our cloud support and web site work.
We need to invent a whole new kind of Snap! account for students to use, separate from their personal account. So if you take a class that uses Snap!, your school would give you a Snap! account. That account wouldn't be able to publish projects, or to share them outside of that class, or to join the forum, etc. This is not the way we like to work! But since you'd still have your personal account, it'd be okay. It would just mean that the projects you make as school assignments would be kept private, unless you take the trouble to copy the project to your personal account of course.
This involves changes to the cloud server (which has to remember what kind of account you're logged in with), the web site (which won't let you comment on other people's projects, once we have comments, for example), and to a lesser extent to Snap! itself (which won't let you publish projects from a student account).
On top of that, we have a modified version of the standard school contract that has to be approved by the Berkeley contracts office -- we aren't allowed to make legal commitments in the name of the university, only the contracts office has that authority -- and that work is happening in parallel with the technical work.
So, yeah, a lot of other things are going to have to wait. Separating media from code in the cloud is one of those things.
Thanks for the kind thought. Jens isn't going to allow volunteers to work on Snap! itself; he says it takes longer to review other people's code than to write it himself, because he doesn't want the code to start looking like the typical collectively written free software, full of band-aids over bugs.
There are probably side things that volunteers can help with; translation to languages other than English is an example.
and btw why is it called the University of California, Berkeley rather than Berkeley University of California