You are not logged in.
Pages: 1
AB,
in case someone wants to add a different/modified protocol it would be better to store the names of the protocols in some sort of extendable list.
Also it might help code maintainability if the protocol names were not used directly as strings. Mapping the strings to constants and using those constants in the code seems better to me.
function TSynopseServerProtocol.GetSubprotocols: RawUtf8;
begin
// mormot.net.ws.core's TWebSocketProtocolRest variants
result := 'synopsejson, synopsebin, synopsebinary';
end;
function TSynopseServerProtocol.SetSubprotocol(
const aProtocolName: RawUtf8): boolean;
begin
result := FindPropName(
['synopsejson', 'synopsebin', 'synopsebinary'], aProtocolName) >= 0;
end;
Last edited by Leslie7 (2021-09-03 19:57:52)
Offline
The protocols are already in a list, each one with its own class for its own process.
So the system is already extensible. Just define your own custom class for a given protocol.
This is what is done in mormot.net.relay, as you quoted in the source code.
This unit demonstrates how to define some protocols, and just relay the frames.
It is a specific use-case.
Check how TWebSocketProtocolBinary are implemented in mormot.net.ws.core, for the actual (not-relay) protocols.
This is not just a list of protocols: this needs some methods to react to the diverse protocols, e.g. 'synopsebin' vs 'synopsebinary'.
I don't understand what your expectations are, and what you are actually proposing as enhancement.
If your proposal is to use constants, why not, but it is clearly a detail, because they are used only on the implementation side of the classes, not in the end-user code, and not subject to change.
For a regular protocol with no sub-protocol, e.g. 'synopsejson', the constant is used only once, e.g.
constructor TWebSocketProtocolJson.Create(const aUri: RawUtf8);
begin
inherited Create('synopsejson', aUri);
end;
Offline
Pages: 1