2020-03-14 13:56 AEST by Arthur Barrett - There must be a way now of using HTTPS for CVSNT client/server communications. 

Eg: using ‘keep alive’ and encapsulation the binary stuff a bit like streaming... or something. 

Indeed to check if authenticating once per connection is reasonable or if the here are risks to this. 

We could use port 443 or still use 2401.

2020-03-26 13:00 AEST by Arthur Barrett - If we made it HTTP/2 we could use a single connection for the entire 'conversation' and use 'http server push' 
to send data to the client without a corresponding client request.
https://en.wikipedia.org/wiki/HTTP/2

Alternatively we could use something like AJAX to send and recieve data requests encapsulated as XML or 
JSON.  
https://en.wikipedia.org/wiki/Ajax_(programming)

Note: CVS/CVSNT server has always processed a 'single' request and then exited.  The client doesn't "remain 
logged in" and there isn't a correspondence between server processes and "logged in users".  In this way it is 
quite similar to HTTP processing.  We have considered over the years if it's worth creating a 'stateful' CVSNT 
where you log in and remain logged in - but that really only works well on a LAN, not a WAN.  So this proposal 
is still for a 'stateless' protocol.  

Note: The biggest effort would be in 'wraping' the protocol up - but with the proliveration of 'minimising' and 
binary data and the fact that it would be encrypted anyway - I do wonder if we'd really really need to be too 
strict.  If we just start it off with a clear HTTP/2 negotiation, then would that be enough?

Note: the big 'danger' with an HTTP protocol for CVSNT is that people would expect it to work with other 
HTTP authentication plugins etc. which really means turning the server into an apache module (or nginx):
https://httpd.apache.org/docs/2.4/mod/
or
https://www.nginx.com/resources/wiki/modules/

Of course SVN trod this path many years ago with mod_dav_svn but that didn't help it stay relavent in the face 
of Git.  Goit of course popularised itself mostly by using SSH as the serving protocol, but now many 
customers use the 'smart http' option:
https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols

How Git implemented HTTP protocol simply by supplying a CGI that works with Apache may be an interesting 
option (their client has to send via HTTP, but the server doesn't have to know HTTP):
https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP