On 2013-01-29 19:49, Paul_Koning at Dell.com wrote: On Jan 29, 2013, at 1:44 PM, Johnny Billquist wrote: On 2013-01-29 16:52, Paul_Koning at Dell.com wrote: On Jan 29, 2013, at 10:43 AM, Johnny Billquist wrote: On 2013-01-29 15:36, Brian Schenkenberger, VAXman- wrote: Johnny Billquist <bqt at softjar.se> writes: ... So we'd need to do some changes to the http protocol to adopt it on DECnet... Johnny That should be completely trivial. First, you assign an object number (pick a number -- 80 would be an obvious choice). Then you send the data across a DECnet connection. That too is easy. Yes, DECnet sends packets, not just a dumb byte stream. So it has structure, IF you need it. If you don't, just pour the bytes into the packets and send them. Ultrix does that -- its DECnet sockets have both a packet and a stream mode. I'm not entirely sure how stream mode behaves; my guess would be that it just sticks the stream into packets whichever way is convenient. As for the blank lines, that's not an issue. A blank line is \r\n (or maybe just \n) but it certainly is not a null string. So an HTTP request would live inside a packet that contains the text of the request, WITH the newline characters. Well, I don't expect there to be much work, but it will also not be just a search and replace of a bunch of calls. Anyway, if anyone ever want to actually do it, we can talk details. It would be fairly straight forward to adapt my server to talk DECnet. Johnny I was talking about changes needed at the protocol level. The API level is a different question, that depends on the OS. For example, on Ultrix and Linux it should be no harder than the protocol changes since both support DECnet sockets. On other operating systems, the simplest port might be to fake up a "decnet socket" library, so the main program code won't see the rather different API used to talk to DECnet. Hardest would be RSTS because it expects applications to do the NSP message segmentation and reassembly rather than doing it in the kernel as is done by most other operating systems. I was actually talking about protocol changes as well, as if it had only been API changes, then it would have been trivial (well, as far as just changing from TCP to DECnet can ever be trivial). Protocol wise, you could (I guess) just decide to append a CR+LF to each record sent, and then strip those off at the receiving side before processing the data. But that is a protocol change, as these would need to be explicitly added and removed inside the packets sent in DECnet. Also, I guess each packet would be a full line, although doing data merging of packets on the receiving side to get lines could also be done. Well, actually, http already specifies the CF+LF on each record. The issue is the implicit extra information received by doing packets instead of a stream, but you could just ignore the record metadata, and look at it as a stream of bytes. It does, however, still force you to define that this is how http should be done on top of DECnet, which today is not "defined". Like I said, I became aware of the issues when doing some MAIL-11 stuff. MAIL-11 sends each line of a mail, as well as various control information in records. It's implied that there are a newline after each record when we talk about the mail body. The TCP interface in RSX is just a device, which makes it pretty trivial to write code that talks TCP/IP. Changing to DECnet means removing all the nice and easy PRINT and INPUT lines, and instead call explicit DECnet send and receive functions. Johnny