On Fri, Nov 19, 2010 at 8:57 AM, Leigh L. Klotz, Jr WA5ZNU <[email protected] > wrote:
> On 11/19/2010 08:17 AM, Brian Lloyd wrote: > > > > On Fri, Nov 19, 2010 at 1:01 AM, w1hkj <[email protected]> wrote: > >> Leigh L. Klotz, Jr WA5ZNU wrote: >> >>> >>> I agree this is what it is doing but it doesn't do what I had thought it >>> would do" >>> 1. put a bunch of spaces in the TX buffer >>> 2. press a macro button with <CLR2X><TX><CALL> DE <MYCALL><RX> >>> 3. RESULT: it still sends the spaces; DESIRED RESULT: it doesn't send the >>> spaces. >>> >>> I can see how this may be hard with the macro invocation separate from >>> the macro interpretation. >>> I'm not sure this current behavior is useful; we on the list seem to >>> agree on that point. >>> >>> Leigh/WA5ZNU >>> >> >> OK Leigh etal, >> >> I will go back and see what an be done to achieve your requested behavior. >> > > Dave, > > There is a definite need for a macro atom that will clear the TX buffer > up to the point of that atom and then begin immediate transmission at that > point. This is analogous to the TCP 'push' and 'urgent' control bits, i.e. > "read and discard everything in the buffer up to this point and then begin > processing everything after to the application." While not used too much > anymore in todays faster networks, it was critically necessary for sending > things like the attention character (^c) over a slow path to a telnet > application. I think we can probably agree that something like this would be > useful when sending using a low-speed transport. > > As we move to future systems where we are passing message and control > data over internet protocols it makes a lot of sense to see where the > application can better make use of the behaviors of the underlying > transport. > > But I would also want one that just works for visually formatting my TX > and RX buffers when interleaving both TX and RX data. I think you really are > talking about two different atoms here. > > -- > Brian Lloyd, WB6RQN/J79BPL > 3191 Western Dr. > Cameron Park, CA 95682 > [email protected] > +1.767.617.1365 (Dominica) > +1.931.492.6776 (USA) > (+1.931.4.WB6RQN) > > > _______________________________________________ > fldigi-alpha mailing list > [email protected]https://lists.berlios.de/mailman/listinfo/fldigi-alpha > > > This is indeed what I wanted, but if it's too hard (or too hard for now) > then I'll just take a look at the macro output space problem (unless Dave > does). > > You might remember with urgent data that Berkeley implemented it improperly > in their TCP stack and instead of giving you the pointer to the urgent data, > it retrieved the single byte at that location in the stream and handed it to > you, as in "Urgent data: 42". That may be one reason it didn't gain the use > it originally was designed for, even though other TCP stacks prior to > Berkeley Unix did it correctly. The analogy fails to some degree, though, > in that the urgent data pointer is processed on the RX side, and the cleartx > is for the TX side. > Ah, a fellow pedant. You are absolutely right and that obscures the point. If you wish to be *completely* pedantic, it was done that way because the application had no way to control the behavior of the underlying transport because of the intentional opacity of layering. (No need to worry your pretty little head about such things my dear. :-) The data may or may not have been transmitted and the data may or may not have been combined into a single segment or separated into multiple segments at the whim of the transport layer. Therefore there was no way to dictate behavior in a determinate fashion on the transmission end. But the larger point is, there needs to be a way to say, "forget all that other stuff I gave you, start here because it is really important." ;-) -- Brian Lloyd, WB6RQN/J79BPL 3191 Western Dr. Cameron Park, CA 95682 [email protected] +1.767.617.1365 (Dominica) +1.931.492.6776 (USA) (+1.931.4.WB6RQN)
_______________________________________________ fldigi-alpha mailing list [email protected] https://lists.berlios.de/mailman/listinfo/fldigi-alpha
