Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,210 of 4,255    |
|    mutazilah@gmail.com to All    |
|    Re: com port    |
|    03 Aug 22 15:36:27    |
      From: muta...@gmail.com              On Wednesday, August 3, 2022 at 10:59:45 PM UTC+8, JJ wrote:       > On Tue, 2 Aug 2022 12:45:53 -0700 (PDT), muta...@gmail.com wrote:       > >       > > You just described what currently happens.       > >       > > I just described what could happen, including the ability to seek.       > >       > > Is there a reason why my proposal wouldn't work?       > >       > > Assuming my proposal would work,       > > does it provide a new conceptual model       > > for accessing external files?       > >       > > Perhaps the simplest form of networking?       > To achieve what you want, there has to be an application at each endpoint.       > The implementation can not be done only at one endpoint. There has to be at       > least the server and the client part to communicate between endpoints, since       > serial port has no concept of file size (and file pointer).       >       > Serial port's lines/statuses are meant for handling the communication       > between two serial port endpoints, which includes data flow. While they can       > be used for application level communication, it would decrease the       > communication handling capability. e.g. no way to know whether the other       > endpoint is ready to receive data or not; or no way to interrupt and notify       > the other endpoint that, the received data is corrupted and needs to be       > resent.       >       > Since `file` exists in application level implementation, anything related to       > it should be implemented at application level rather than hardware level.       > Hardware things have their own purposes for good reasons. Reusing them for       > application things would decrease the hardware's basic capability and/or       > performance. That should only be done if the two endpoints is connected       > using only 3-wires cable, instead of the full e.g. 7-wires cable. It's not       > wrong, but it should be avoided.              Hi JJ. Thanks for your thoughtful response.              Do you think, with the benefit of hindsight, there should have been a       mechanism for what we now know as host file access?              The method above, abusing the hardware, is not the only       method I have used. My pdos-generic code is already capable of       this, but relies on a cooperative bios.              The hardware could also have been designed with       another wire if you think the existing wires cannot be       repurposed.              It's a good point that with a serial cable you could       have data corruption so ideally you want a crc and error       correction. When that is added do you end up       with SLIP/PPP?              Maybe this crude method, relying on error-free       communication, could be used while waiting for       SLIP/PPP to be implemented?              Paul.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca