Deutsch English Français Italiano |
<8wKdneDRJ5x_z274nZ2dnZfqn_adnZ2d@giganews.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!69.80.99.26.MISMATCH!local-2.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 14 Mar 2024 19:41:22 +0000 Subject: Re: Meta: a usenet server just for sci.math Newsgroups: sci.math,news.software.nntp References: <8f7c0783-39dd-4f48-99bf-f1cf53b17dd9@googlegroups.com> <31663ae2-a6a2-44b8-9aa3-9f0d16d24d79o@googlegroups.com> <6eedc16b-2c82-4aaf-a338-92aba2360ba2n@googlegroups.com> <51605ff6-f18f-48c5-8e83-0397632556aen@googlegroups.com> <b0c4589a-f222-457e-95b3-437c0721c2a2n@googlegroups.com> <5a48e832-3573-4c33-b9cb-d112f01b733bn@googlegroups.com> <8wWdnVqZk54j3Fj4nZ2dnZfqnPGdnZ2d@giganews.com> <MY-cnRuWkPoIhFr4nZ2dnZfqnPSdnZ2d@giganews.com> <NqqdnbEz-KTJTlr4nZ2dnZfqnPudnZ2d@giganews.com> <FqOcnYWdRfEI2lT4nZ2dnZfqn_SdnZ2d@giganews.com> <NVudnVAqkJ0Sk1D4nZ2dnZfqn_idnZ2d@giganews.com> <RuKdnfj4NM2rlkz4nZ2dnZfqn_qdnZ2d@giganews.com> <HfCdnROSvfir-E_4nZ2dnZfqnPWdnZ2d@giganews.com> <FLicnRkOg7SrWU_4nZ2dnZfqnPadnZ2d@giganews.com> <v7ecnUsYY7bW40j4nZ2dnZfqnPudnZ2d@giganews.com> <q7-dnR2O9OsAAH74nZ2dnZfqnPhg4p2d@giganews.com> <QrWdnaIk98Ulgnv4nZ2dnZfqnPVi4p2d@giganews.com> <iWGdndu1WIJLe3T4nZ2dnZfqnPcAAAAA@giganews.com> <TNqdnUdkktOxEW34nZ2dnZfqn_YAAAAA@giganews.com> From: Ross Finlayson <ross.a.finlayson@gmail.com> Date: Thu, 14 Mar 2024 12:41:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <TNqdnUdkktOxEW34nZ2dnZfqn_YAAAAA@giganews.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <8wKdneDRJ5x_z274nZ2dnZfqn_adnZ2d@giganews.com> Lines: 179 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-26udhPLjjjq6er081QJF8Wo57R446yI8HsXUBZ7UIl/MnEmzhSLO/CtQ9KScPUdJSTVyO4Yf2AHsG9a!1kZPU/Plvys62GOI+j9rv8J+OGOJsjBp7hfPURTR+w3R/W+/vGTh9E4KY4s5+TRjteSc2H3wx4EF X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 10691 On 03/12/2024 10:09 AM, Ross Finlayson wrote: > So, the usual abstraction of request/response, > and the usual abstraction of header and body, > and the usual abstraction of composition and transport, > and the usual abstraction of multiplexing mux/demux, > and the usual abstraction of streaming and stuffing, > and the usual abstraction of handles and layers, > in the usual abstraction of connections and resources, > of a usual context of attachments and sessions, > in the usual abstraction of route links and handles, > makes for a usual abstraction of protocol, > for connection-oriented architectures. > > Hipoio "Protocol" and "Negotiation" The usual sort of framework, for request/response or message-oriented protocols, often has a serialization layer, which means from the wire to an object representation, and from an object to a wire representation. So, deserializing, involves parsing the contents as arrive on the wire, and resultingly constructing an object. Then, serializing is the complementary converse notion, iterating over the content of the object and emitting it to the wire. Here the wire is an octet-sequence, for a connection that's bi-directional there is the request or client wire and response or server wire, then that usual matters of protocol, are communicating sequential processes, either taking turns talking on the wire, "half-duplex", or, multiplexing events as independently, "full-duplex". So, the message deserialization and message composition, result in the protocol, as about those get nested, what's generally called "header and body". So, a command or request, it's got a header and body, then in some protocols that's all there is to it, while for example in other protocols, the command is its own sort of header then its body is the header and body of a contained message, treating messages first class, and basically how that results all sorts of notions of header and body, and the body and payload, these are the usual kinds of ideas and words, that apply to pretty much all these kinds of things, and, it's usually simplified as much as possible, so that frameworks implement all this and then people implementing a single function don't need to know anything about it at all, instead just in terms of objects. Protocol usually also involves the stateful, or session, anything that's static or "more global" with respect to the scope, the state, the content, the completions, the protocol, the session, the state. The idea then I've been getting into is a sort of framework, which more or less supports the protocol in its terms, and, the wire in its terms, and, the resources in their terms, where here, "the resources" usually refers to one of two things, the "logical resource" that is a business object or has an identifier, and the "physical" or "computational resource" which is of the resources that fulfill transfer or changes of the state of the "logical resources". So, usually when I say "resources" I mean capacity and when I say "objects" it means what's often called "business objects" or the stateful representations of identified logical values their lifecycle of being, objects. So, one of the things that happens in the frameworks, is the unbounded, and what happens when messages or payloads get large, in terms of the serial action that reads or writes them off the wire, into an object, about that it fills all the "ephemeral" resources, vis-a-vis vis the "durable" resources, where the goal is to pass the "streaming" of these, by coordinating the (de)serialization and (de)composition, what makes it like so. start ... end start ... first ... following ... end Then another usual notion besides "streaming", a large item broken into smaller, is "batching", small items gathered into larger. So what I'm figuring for the framework and the protocols and the negotiation, is what results a first-class sort of abstraction of serialization and composition as together, in terms of composing the payload and serializing the message, of the message's header and body, that the payload is the message. This might be familiar in packets, as, nested packets, and, collected packets, with regards to that in the model of the Ethernet network, packets are finite and small, and that a convention of sockets, for example, establishes a connection-oriented protocol, for example, that then either the packets have external organization of their reassembly, or internal organization of their reassembly, their sequencing, their serialization. Of course the entire usual idea of encapsulation is to keep these things ignorant of each other, as it results making a coupling of the things, and things that are coupled must be de-coupled and re-coupled, as sequential must be serialized and deserialized or even scattered and gathered, about then the idea of the least sort of "protocol or streaming" or "convention of streaming", that the parsing picks up start/first/following/end, vis-a-vis that when it fits in start/end, then that's "under available ephemeral resources", and that when the message as it starts getting parsed gets large, then makes for "over available ephemeral resources", that it's to be coordinate with its receiver or handler, whether there's enough context, to go from batch-to-streaming or streaming-to-batch, or to spool it off in what results anything other an ephemeral resource, so it doesn't block the messages that do fit, "under ephemeral resources". So, it gets into the whole idea of the difference between "request/response" of a command invocation in a protocol, and, "commence/complete", of an own sort of protocol, within otherwise the wire protocol, of the receives and handlers, either round-tripping or one-way in the half-duplex or full-duplex, with mux/demux both sides of request/response and commence/complete. This then becomes a matter relevant to protocol usually, how to define, that within the protocol command + payload, within the protocol header + body, with a stream-of-sequences being a batch-of-bytes, and vice-versa, that for the conventions and protocols of the utilization and disposition of resources, computational and business, results defining how to implement streaming and batching as conventions inside protocols, according to inner and outer the bodies and payloads. The big deal with that is implementing that in the (de)serializers, the (de)composers, then about that a complete operation can exit as of start -> success/fail, while commence might start but it can fail while then it's underway, vis-a-vis that it's "well-formed". So, what this introduces, is a sort of notion, of, "well-formedness", which is pretty usual, "well-formed", "valid", these being the things, then "well-flowing", "viable", or "versed" or these automatic sorts of notions of batching and streaming, with regards to all-or-none and goodrows/badrows. Thusly, getting into the framework and the protocols, and the layers and granular and smooth or discrete and indiscrete, I've been studying request/response and the stateful in session and streaming and batching and the computational and business for a long time, basically that any protocol has a wire protocol, and a logical protocol above that, then that streaming or batching, is either "in the protocol" or "beneath the protocol", (or, "over the protocol", of course the most usual notion of event streams and their batches), is that here the idea is to fill out according to message composition, what then can result "under the protocol", a simplest definition of (de)serialization and (de)composition, for the well-formedness and well-flowingness the valid and versed, that for half-duplex and full-duplex protocols or the (de)multiplexer, makes it so possible to have a most usual means to declare under strong types, "implement streaming", in otherwise a very simple framework, that has a most usual adapter the receiver or handler when the work is "within available ephemeral resources", and falls back to the valid/versed when not, all the through the same layers and multiplexers, pretty much any sort usual connection-oriented protocol. Hi-Po I/O ========== REMAINDER OF ARTICLE TRUNCATED ==========