Hu: I have invested, personally, over $3-mn in software development, with A-listers who later went on to Microsoft, Facebook, and the like, researching, cultivating, some of the best lines of code, ever written, discretely, in these technologies, and I now seek, in the 2020s, to put them together, into a single | web product.
H3S1: This platform is relentless cross-platform:
Hu, @Charlotte O’Connell<fbno>: The limitation of Swift is that you only can use it for iPhone apps. If you use Swift, you’ll need Java for Android, and something else, still, for web, like PHP. If you use React, you’ll have a single programming language for both iOS and Android, but, unless your website is in server.side-JavaScript, which is not the most popular, PHP is the most popular, you’ll need 2 programming languages. If you use PHP x Laravel, which is also a PHP framework, you can use the same server, for all 3.
H3S2: This platform contains coldest to warmest<Turing!><McLuhan!><fbno>
H3S3: This platform, through and through, is base-protocol:
Hu: It’s important to note # that BOWSER is a stack to rule, but not the final | stack; as a good ruler, it is a platform, upon which many future protocols, can be built.
H3S4: This stack is max-red:
H3S5: This stack is logically coherent:
H3S6: A holistic application, built.stack-this, will be MVP-internet:
Hu: The true vision of the original–internet will not have been fully realized, even in an MVP, until an app.of-this,stack<fbno> is built.
H3S7: 10 commandments of BOWSER:
H4S1: WebRTC will be used to transfer all MP4, both sync and async, temp and stored, 1-way, and 2-way, broadcast, and convo<Turings!>
H4S2: Content that is streamed and saved must not be sent twice:
H4S3: MySQL must be configured to be equivalently real-time to WebSockets<Turing!>
H4S4: Peer-to-peer connections will handle all streamed, but not saved, interactions, past the 30 minute mark<Turing>:
H4S5: Peer-server-peer will handle all connections, except H4S4:
H4S6: All client experiences will be served by a standard.web-browser, device-agnostic<Turing>
H4S7: A single web-server, main, with distributed service servers, p.dash-layered #, will process all data:
H4S8: BOWSER is domain-agnostic, and can be distributed across an infinite #; however, there will be only 1 user-tb<Turing><dirty!>
H4S9: BOWSER is written in the conditional.programming-paradigm: <WP.MIC-H2S58>
Hu: The only paradigm that is concise enough to handle the load of user-interactivity that BOWSER will pose is conditional-programming<Turing>
H4S10: Only chess programmers will be qualified to build BOWSER-applications:
Hu: Welcome to the future. Get training: https://lichess.org/training/mateIn5
H3S8: Differential.corporate-backing,analysis: <Turing><#n.p-Econ>
H4S1: MySQL’s history with Oracle:
Hu: MySQL has much more in depth docs than PHP, and is the only open sourced component # of BOWSER that is owned by a large corporation $203-bn, 10/27, which has the resources to maintain the docs at an adequate level. Therefore, it makes sense to invest deeply in this component of the stack, and rely upon it for scalability. Much of our programming will be done with INDEX and table design in MySQL, to reduce script load, and optimize load times. X.ref-<WP.MIC-H2S30>
H3S9: PHP’s role in BOWSER:
<Lengstorf, Leggetter pg-26> If JavaScript/jQuery is half the brain of our app, PHP will be playing the role of the other half. It will do the heavy | lifting as far as processing the data sent to the app by our users and sending back processed responses to various user | requests.
H3S10: Web.Socket-RTC role in BOWSER:
Hu: These transmission protocols will substitute HTTP, but as always, we will #V-T every implementation. At the core, we will be doing condition.oriented-prog, and we will think of $msg, generally, as a type of thing that the user wants to send, and it can be sent, through any which protocol, so our Web.Socket-statements will be used, as intermittently, as our MySQL-statements, have been, so far. You will find hidden.Socket-calls, often, layered, and controlled, conditionally, in complex conditional and loop functions, and rarely, except but in the includes, will multiple lines of code be exclusively dedicated to some Socket-write, and this will be reflected in the UX, in order to achieve a true cold.to-warm,exp.
H4S1: The user wants content delivery to be as fast as reasonable:
Content is content, and the delivery of content, situational; in certain cases, we want it there instantly; in certain cases, we want it there in a couple minutes, but it’s not immediate; in certain cases, the same message, or even to a different recipient, we can get it there in hours. This is our experience of the world of content, and our architecture design, which includes Web.Socket-RTC, as the fastest possible layer, accounts for this. Just as we don’t try to squeeze-hole # all content, and delivery moments, through any one other paradigm, we also won’t, through Web.Socket-RTC.
H4S2: WebSockets should handle exactly 50% of all text-transactions<Turing>#defd:
Hu: WebSockets involves a single half-duplex instance, which is substituted, in fact, by an HTTP request, to open the connection, since this is a one-way request from a browser, and the server is always ready. Following this, all full-duplex, ie, when there needs to be simultaneous sending and receiving, should be handled, by definition, by WebSockets, and this also defines real-time, and vice versa. In other words, real-time can be defined by bidirectionality, and synchronicity, as much as it can be defined, by the speed of a content’s delivery.
H4S3: Exactly half of WebSockets transactions should be server-server<Turing>:
<WP.MIC-H2S76> The thematic component of half.duplex-comms is that it is client–server, and even in a client.server-server,client architecture, to some extent, that client-server component, will continue to be a half-duplex. However, more of the web’s total transaction volume should be server-server, with 2 backends, talking to each other, as a server-require<Turing>, that dramatically enhance any solo-node’s ability to solve a client’s request.
H3S11: The role of networking in BOWSER:
Hu: The networking capabilities I need, in both use cases, is HTTP, and TCP; there does not need to be specific WebSocket support; however, beyond the networking capability, I also need firewall, and browser permissions<WP.MIC-H2S55>
References:
https://en.m.wikipedia.org/wiki/MySQL
Beginning HTML5 and CSS3 <2012>, by Christopher Murphy, Richard Clark, Oli Studholme, and Divya Manian. https://link.springer.com/book/10.1007/978-1-4302-2875-2
Realtime Web Apps by Lengstorf and Leggetter, via Apress.