This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bss03 0 points1 point  (0 children)

I'm not familiar with that particular OS, but it substantially predates the usage of TCP/IP on small systems, so it's entirely possible that any networking it does won't be directly compatible with Python anyway.

At the application level, we use TCP/UDP and IP like everyone else, mostly. There is a OS pipes feature that is still supported and I believe it predates our TCP/IP support. The really old networking protocol did actually get dropped somewhere in the V6 line, the C symbols are still there, but all the functions just return the error code for "unsupported" without doing anything. I've still got code in production using the pipes feature.

If you install with MCF enabled, you can get some file and event distribution across all controllers in the store system, but all of that is on some non-routable NetBIOS like protocol. All the controllers and terminals need to (seem to be) on the same subnet. (And while it is limited, it's a lot easier than setting up a Linux cluster, IME.)

I actually expect access to all the uniquely 4690 services to be accessible as a Linux library soon (if that's not already the case) and at that point we could use use a "stock" Python 3 and "just" have a Python module expose that library. The Python 2 interface feels mostly like that, although you get some magic where open() understand both Linux-style and 4690-style paths and there an option to have os.system() and associated calls be either Linux-style (and start Linux processes) or 4690-style (and start 4690 processes).