We can find times where properties should be or must be set at the LiveCode 'open' or 'accept' for sockets, drivers and processes. Setting the properties afterward might not have the desired outcome.
There might be several ways to do this.
We can be inspired by object templates. Everywhere a socket, driver or process can be used in the above mentioned commands and functions, the template can be used. Like this:
Code: Select all
setSocketProperty templateSocket, "SO_REUSEPORT", true
We would want to reset as we can object templates:
If these include socket options, they should be handled after the higher-level properties in an 'open socket' or 'open datagram socket'. Or maybe some properties are not allowed for IO templates.
There should be some way that these can work well with some of the other ways we have to handle this now:
- allowDatagramBroadcasts
defaultNetworkInterface
hideConsoleWindows
serialControlString
What have I missed that belongs in this list?
These might be views into I/O templates. For example, setting the serialControlString sets the appropriate properties in the templateDriver (the template for serial I/O) and getting it builds it based on the templateDriver. If new allowed values are added in the properties for properties also reflected in serialControlString, the serialControlString should be enhanced to be consistent. If possible the serialControlString should have some level of compatibility with mode in Windows, but I don't think that is a strong druther as long as there is an easy way to descriptor the difference.
There are potential problems if the current methods trigger some song-and-dance in open to get around bugs and quirks on some platforms and OS versions. The corresponding properties might need the matching level of abstraction and good service.
(We use serial in serialControlString and driver in driverNames. Unless we see drivers as becoming more general than serial, then maybe all places they can be sub-name synonyms. Or will that explode?)
I don't think the current methods for setting up I/O open should be depreciated, they might have good pedological uses. Also, serialControlString might be nice for people coming from some other Windows programming environment.
Have I wandered off way beyond where the lifeguard can see me?