H2S105: Base^2 Stream Content: Dynamic User.Gen-Control,Test!

Hu: WebSockets and all these protocols might all be written for asymmetrical peers, to standardize communication, but if I’m writing internally, I might just be able to strip bare, or even invent my own simple paradigm, just using sockets and fwrite. Once I figure out the resource ID, make a simple test, where I can get text to show up on a page, dynamically, and remotely, whether from the same page via input, or another page. This is the max red test of stream control<WP.MIC-H2S61,H3S3>.

The page in which the content will be dynamically live # displayed needs to have an fread to a specific resource, and the fwrite whether from this page, or another, needs to go to the corresponding resource, first WebSockets sentence at p-dash reasoning, corresponds this to programming speed now.

H3S1: Remote | User-controlled | Dynamic-updating Files is the base-red<fbno><Turing>:

What are we ultimately trying to do in the end? It helps to have a use case: we are trying to have one file remote write, to another file, or the display of that file; the write can be ephemeral, or permanus; if it is permanus, then a db-write will also have to be made. The write action is triggered from the writing file, and that trigger can be mapped to a user interaction gesture. The most basic example, is on one file, or the file of one user, even if it can be the same file #, a user types the letter ‘a’, and that letter ‘a’, is written to the recipient user’s file, such that it appears on the screen; independently also from the writing, is how that ‘a’ input is processed by the receiving file, to be displayed, such as where it is displayed, and with what CSS-params, and so forth.

The concept of a stream is not inherent in this basic action sequence. The stream is what is required by PHP’s fwrite function; that’s why it exists. This means that fwrite is an order of magnitude more fundamental than the stream, and yet, nobody talks about it, thematically, if hardly ever, even someone talks about the stream, which is an order of magnitude more fundamental than the protocol. I hear about the word protocol, but even that, is not what they are talking about; they are just talking about some code to use the protocol, so they use the word code, but they don’t understand what it means. Therefore, they are at least 4 fundamental steps, in terms of layers of abstraction, removed from the base layer, which is fwrite.

The stream is a necessary |component, for PHP, of the fwrite action. Why? Because Lerdorf wrote it in the docs:

fwrite(resource $stream, string $data, ?int $length = null): int|false

Hu: So, the extent to which we need to ask why we even need a stream, when all we want to do, is live-update a file, can be attributed, simply, to “Lerdorf decided that’s how he wants to implement it”, and this is primarily a historical | reason. Lerdorf is just one man, he’s not God, and neither is anyone else, who is building frameworks, and libraries, that serve filesystems<Turing>; he has a paradigm, and builds, within that paradigm, and you can absorb his paradigm, by watching lecture videos of his, on YouTube<MIC-H2S13>

The stream, as we can understand it, in the context of fwrite, is simply the pathway, from the writing | file, to the writed | file # Without it, the “what” that is written, has no way, of reaching its destination. Another historical | detail of this implementation is that you need not specify the destination of the writed | file when you are doing the write. Again, we can see in PHP’s function requirements, a file | destination is not one of the arguments. Rather, you dump it in a postal | warehouse<Turing>, and attach a resource | ID to the envelope, and the next person who shows up the warehouse, using fread, with that resource | ID displayed on a badge, can pick up the message<Turing>.

Therefore, the fwrite | stream complex in PHP, is less | sophisticated than the actual USPS, which carries millions of mail per day, and therefore, is less | scalable than the USPS itself. That means that fwrite, and stream, was never intended for a mass client-server-client setup, where the entire globe’s messages gets routed through a single central server, like the USPS, handles mail<Turing>.

Once the basic fwrite | stream complex is established, conceptually, we can understand, that the protocols, which are basically like, instructions for how to | drive on the road, are merely techniques for handling traffic. Such techniques are only necessary if there is traffic; when you are the only car on the road, you can drive as fast as you want, in any which line. The more traffic, the more we need traffic | protocols<Turing-dirty!> to attempt to ensure that each person, on this crowded highway, will still be driving as fast, as the solo-driver #

As on a real highway, each individual car will optimize its mean speed, if all the cars obey a protocol, that minimizes the spatial occupation of each car<Turing>; on the other hand, if cars exhibit maneuvers that take up disproportionate space, suddenly, then all the cars behind them, will be forced to slow down, causing a traffic | bottleneck.

If you are an amateur highway comptroller, or one that is in training, which, at this point, we all are, on the primitive internet, like the first road system in 2,000 B-C, you should probably start by managing small roads, such as the back road between you and your neighbor’s house<Biblical!>, before you immediately jump to drawing up super-highway plans<duh!>

Therefore, when I come across, on Github, plans for a super-highway from someone who does not have experience directing street traffic at their local elementary school, I just write it off, rationally, as a student | project. There’s no reason to expect that such plans would actually be scalable; it’s just an amateur artist, working through his ideas, on the page<Albright-Knox!>

It is well established, in the study of scalability<WP.MIC-H2S4>that one important sin is over-building, developing features, and scalability, before it is needed. Sticking to the absolute MVP is actually an iterable component of scalability, as much as load testing, for the next segment # No companies has ever collapsed, while in possession of a modular system, from too much traffic; the website might crash for a few days, but too much traffic is a good | problem to have, and you can leverage your story of how you crashed, and then build the next layer, because you weren’t expecting to scale so fast, to pitch to investors<Distractify, a-r>

H4S1: How to know, when to read:

The fread | function needs a notification to know when it needs to go to the postal | warehouse to get the mail<Turing>; in event–based | programming, spearheaded by walkor<a-r>, the action of writing to the stream, must, at some stage, trigger the onMessage event<generalized>, and this event, sequentially, will trigger the writed | file, to run fread, which drives to the warehouse.

Note that this implemention is not truly continuous, as the stream concept suggests, by word, or by definition: transmit or receive (data, especially video and audio material) over the internet as a steady, continuous | flow<Ox-Lang>Turing> The discontinuity is for 2 | reasons:

H5S1: The insertion of the warehouse | concept creates a discontinuation in the trajectory of the message, from sender to receiver: Once the message reaches the warehouse, it stops; in a physics sense, it totally loses its momentum, while the program execution waits for onMessage to trigger fread. The message is not sent continuously, all the way, from the writing to the writed, as a non-stopping trajectory<Turing>.

H5S2: fread call fall asleep, but he wouldn’t be able to, in a real conversation: the programming details come across, and the fact that fread call fall asleep, and go to the warehouse much later, to pick up the mail, communicates the fact that any WebSockets implementation that uses the onMessage halt<Turing> is not truly a live | conversation. In a live conversation, the act of speaking, is also the act of listening, and the sound wave produced, instantly received. In truth, even modern WebSockets is just a glorified HTTP-req, except fread is able to run by a trigger, this onMessage event, rather than prompting the user to click to refresh. Yes, that’s it. Therefore, we are as much in the event–server | paradigm as we are in truly real-time comms, the native of which, will arrive with Flare<Hussein Nasser, a-r>.

H5S3: In a real human #<repeatable!>, an elevated set of resources must be consumed, when in a waking, vs dormant state, and even 10% more so still, when someone else is in the room. When there is the possibility of receiving a WebSocket push, as a result of having run stream_socket_client, you are now, in a human perspective, in the same room. This should be reflected, in the allocation of computing resources<Turing>, and it should be noted, that 10% increase in maintenance resources for being alert for continuity # is a much lower effort than being notified to drive to the warehouse, including when you are asleep<jarring!> Again, we should personify what is happening on the server-side and try to match it to a paradigm that is energy efficient, for the human end-user<Turing>