Sorry, I was not clear enough. I would like to experiment with handling multiple different protocol connections that are Non-HTTP coming in from different ports but share some of the resource space on a Solid server such as the locks, access control lists, and resources themselves. I experimented with a pub-sub protocol, however it is a rather hacky solution and I'm trying to developer a better one to incorporate the usage of locks and ACLs better.

Edit: I was looking into it and it appears the ServerConfigurator simply extends AsyncHandler. I could use parallel handlers to handle Non-HTTP compliant requests, but would there be any issues or implications of replacing it with a more generic type such as TestDataConfigurator that extends AsyncHandler or some union type?

I don't have experience with implementing non-HTTP protocols (besides the websocket one) so I don't really know how these are implemented code-wise. But if it's similar to websocket, in that you listen to a specific event and interact with it, I would expect the implementation to be similar. That class would then also have to be added to the urn:solid-server:default:ServerConfigurator so they get access to the server object. That class would then have to call a handler to do something when it receives a request, but which handler that is highly depends on what needs to happen. But they could access the same components as the handler used for HTTP requests.

I appreciate the response. I was hoping for that as well. This is just an experiment and I don't expect anyone to have experience implementing it on a server, especially since Solid is HTTP first. If I just need to play with the ParallelHandler in the ServerConfigurator then I can try some implementations and see what works and what doesn't. In that case, do I need to worry about the generic AsyncHandler and create conforming node:http Server types, or would it be easier to create a ServerConfigurator that extends an AsyncHandler<Server | MyCustomType> union with a type guard in the handling logic? Or is changing the generic of the AsyncHandler even necessary since the types are just a compile-time syntactic sugar?

Easiest would be if you can create a new class that extends ServerConfigurator, the same as for web sockets. You do not want to change the input type of that function as Server is the type of the object that you will receive from the class higher up. Internally you would then do the more specific checks with this object and act accordingly.

Hmm, that may be a problem in my experiment then - since I wouldn't be looking for http-based traffic then I don't think the ServerConfigurator extending AsyncHandler would work, especially since I can see the dependency of it in the BaseServerFactory. I would probably have to create a different instance of the ServerFactory and possibly my own ServerInitializer class as well - that way ports could be opened on the same address which route to various HTTP and non-HTTP handlers but still share the same storage and authn/authz.