> you do want a defined subset of HTTP/(X)HTML. Maybe to make a small web HTTP, servers can reject clients that e.g. send user agents, and clients can refuse to render pages that contain a script tag.
That’s a great idea.
My idea was to go other way a bit re javascript. That is, allowed it to run but it’s under the control of the user, not the website. A bit like installing a native app. For anything functional, why not have companies just send JSON or have an API and the user can display as they see fit. sending sqlite files around would be another option.
I can’t help but thing that in the future people will laugh at how ridiculous we are with stuff like the l fact that the service provider can make me chase my tail around intentionally obfuscated UI in order to cancel.
> [A small web HTTP, with a defined subset of HTTP/(X)HTML is] a great idea.
It is not the only way, although it is one possibility.
> My idea was to go other way a bit re javascript. That is, allowed it to run but it’s under the control of the user, not the website.
Simpler designs can be made than JavaScript with HTML DOM. But, when it can be allowed, yes it should be under the control of the user and not the website.
> For anything functional, why not have companies just send JSON or have an API and the user can display as they see fit. sending sqlite files around would be another option.
I had a similar idea (although I think there are some problems with some file formats such as JSON, too).
However, it does help to be able to specify which files can be used to display unknown files. My Scorpion protocol/file-format specification includes such a feature called a "conversion file"; both server-side and client-side conversion are possible. It is optional to implement, but if it is implemented, the specification requires that the user is allowed to override it with their own specifications if desired.
> Simpler designs can be made than JavaScript with HTML DOM.
I'd agree here for sure. 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. I think the fact that current browsers are 100s of millions of lines of code (or whatever) get in the way of the fact that, at its core, a browser doesn't have to insanely complex.
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.
I've only toyed with a bit, but I think something like the Lua Love2D tool pretty much gets you there. Or any number of approaches.
> although I think there are some problems with some file formats such as JSON, too
Curious what you think those problems are. I'm not defending it particularly and have heard a few valid critiques tossed around online but am always open for hearing how folks think about it. Personally, I'm largely surprised that anything has managed to coalesce into a general format for data.
> My Scorpion protocol/file-format specification includes such a feature called a "conversion file"; both server-side and client-side conversion are possible.
Cool, I'll go take a look for it.
Feel free to ping me at the email in my profile if you're up for kicking any ideas around.
The topic has been sitting on my mind for a long time and I'm glad to get behind anyone's even half plausible technological approach. I think our 60 years of Moore's Law makes any one of a number of approaches possible. But prob not just me plugging away here solo in my living room.
> Feel free to ping me at the email in my profile if you're up for kicking any ideas around.
I did not find a email address in your profile.
However, I have a NNTP server and can use that to set up a public discussion forum for such things. Some of the appropriate newsgroups in Usenet might also be used (e.g. comp.infosystems and/or comp.protocols.misc) if you like to use that.
If you have a GitHub account, then the GitHub issue tracker can also be used for discussion of specific issues with the specific project (the Scorpion protocol/file-format specification, and the programs related to it (e.g. client and server software)).
> 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
The specification file can also be accessed by Scorpion protocol itself, at: scorpion://zzo38computer.org/specification.txt
That’s a great idea.
My idea was to go other way a bit re javascript. That is, allowed it to run but it’s under the control of the user, not the website. A bit like installing a native app. For anything functional, why not have companies just send JSON or have an API and the user can display as they see fit. sending sqlite files around would be another option.
I can’t help but thing that in the future people will laugh at how ridiculous we are with stuff like the l fact that the service provider can make me chase my tail around intentionally obfuscated UI in order to cancel.