On Fri, Jan 1, 2021 at 2:37 AM Raphaël Hendricks <rhendricks@xxxxxxxxxxxx> wrote: > All > this was being done through the working on XHTML 2.0 draft, RDF/RDFA, > the semantic web in general (which would allow better indexing and > content reuse and which would be mostly based on the previously > mentioned languages), XSLT, XForms, XML in general, XInclude, and so > on. > [...] server-side dynamic capability with static-only client > side, except for form-validation through XForms, XML to XML > conversion through XSLT and timing/events thorough XML events and > SMIL animation, or where client side dynamic capabilities are > declarative only, with no imperative support) [... and more and more and more ...] The difficulty with all that is that it is just horribly complicated and constantly growing, one technology after another. What happens then is that it becomes just about as hard to write a browser for XHTML-2.0-plus-long-tail than it is to write on for HTML5/CSS/JS, if not more so. This creates an oligopoly of client software, because nobody except people with strong first-mover advantages can afford to write one. This I consider to be a Bad Thing. > It however needs to > be stated that there are legitimate reasons to wish to run software > operating in a client-server split model, that is not the problem. > The problem is that bastardizing the WWW and the technologies > supporting it is not the proper way to answer this legitimate need. I agree entirely. But piling up another huge stack is not the way to do this part of the job either. If we instead look at design from a perspective of simplicity, we get: JSON and when needed MicroXML for structured data. Gemini (see http://gemini.circumlunar.space for details), a protocol a little more complex than Gopher, but adding mandatory TLS encryption (currently 1.2 or 1.3; in future 1.3 only), content retrieval by URL (which allows virtual hosting, protocol gatewaying, etc), client certificates as a universal authentication mechanism, and responses tagged with media types. In addition, Gemini comes with a new hypertext format, text/gemini, which is also designed to be simple. In a year and a half of very low voltage development, dozens of clients and servers have been made available already. Gemini clients, rather than document authors, decide how texts are to appear. However, the Gemini protocol can support arbitrary media types including HTML. There are two sister protocols, Titan for uploading content and Dioscuri for sending and receiving entity bodies in a single transaction. However, there is no need for Gemini browsers to support either of them. > There is > also a need for a technology to run client-side software that > connects to remote software running on the server; this type of > technology, with client software connecting to software running on a > server, is the right way to handle transactional operations such a > banking and stock buying as well as online shopping; I agree. In order to manage this from the same simplicity and safety viewpoint, I believe that a new programming language is needed: easy to use for all programmers from beginners onward, with textual and bytecode representations, and pre-sandboxed rather than running in a sandbox. I am working on such a design: see <http://tinyurl.com/avsl-nutshell>. AVSL is a temporary name, meaning "A Very Simple|Small|Safe Language". Comments on the language can be sent to me. John Cowan http://vrici.lojban.org/~cowan cowan@xxxxxxxx If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton
