> I suppose I was thinking that if JSON (or any other basic format) was specified in and out from companies, etc; a client-side browser replacement could be abo

> I suppose I was thinking that if JSON (or any other basic format) was specified in and out from companies, etc; a client-side browser replacement could be about anything. Yes, and I think that such a thing (whether or not it uses JSON) is helpful. However, there would then also be something to specify display of such files (which the user can easily override with their own). > You need a way to put info on a screen and a way to talk over the network. That's pretty much the core. Not hard to add some flavor of storage and/or scripting client-side. Yes, and there are ways to do it. I think that uxn/varvara is a simple way to do it (especially if you only need one network connection at a time, since it can be connected to the standard I/O; you can disable the file device for security if desired), and is what the Scorpion conversion file specifies (although the conversion file is flexible and can be used to specify other things too, such as server-side conversion). It doesn't need to be mandatory for clients to implement all (or any) of the features. But, if some features are implemented and the user is not required to use those provided by the server, and can also provide their own (the specification for the conversion file Scorpion protocol, requires this), then it can be less of a problem. (The use (and presence) of the conversion file itself is deliberately made optional, though.) > a browser doesn't have to insanely complex. Certainly it shouldn't have to be insanely complex, if it is better designed. > Curious what you think those problems [about JSON] are. Criticisms of the data model: - Not a proper integer type. Although you can write 64-bit (and longer) integers, the corresponding type JavaScript is 64-bit floating point, and long integers are unlikely to work even in implementations that do not use JavaScript. (JavaScript does have a big integer type but these are not used in JSON.) - Unicode string types. The use of Unicode string types in programming languages and general-purpose file formats isn't very good. It can be inefficient and can make assumptions that are not always valid such as that all data is text and that all text is Unicode and that all file names are Unicode, and then there is the handling of surrogates, etc. Byte strings are better; you can still store Unicode text with byte strings, but also any other data. (Using hex or base64 to the data model just adds additional steps; although such features could be appropriate for the text-based syntax of the file format.) - Keys. They are influenced by the way keys are handled in JavaScript, which sometimes has some special cases that are not as clean as they could be. (In JavaScript you can use Object.create(null) to avoid the automatic handling of the keys that are inherited from Object.prototype, but this does not apply to the literal object syntax.) (I think keys should be integers and byte strings; JSON only allows Unicode strings, and JavaScript does not distinguish between numbers and strings as keys.) Criticisms of the syntax: - No optional trailing commas (even though JavaScript allows it). - No comments (even though JavaScript allows it). The things mentioned in the syntax are not applicable for binary formats (although different considerations may be relevant), although can be relevant if you want a text format as well. (One possible alternative would be a subset of PostScript, rather than a subset of JavaScript. PostScript already has a binary format as well as a text format (although the binary format cannot use numbers longer than 32-bit integers and 32-bit floating point; and limits strings to 64K; these limits might be too small for some applications), has byte strings, has a hex syntax for byte strings, and does not use commas between items.) > Cool, I'll go take a look for it. There is a GitHub repository of Scorpion protocol/file-format specification (and some programs) at: https://github.com/zzo38/scorpion https://github.com/zzo38/scorpion The specification file can also be accessed by Scorpion protocol itself, at: scorpion://zzo38computer.org/specification.txt