create a wishlist section in the readme

some TODO items have been turned into wislish items because that's more appropriate for them and it reduces code clutter

Author: ThetaSinner

README.md

@@ -4,6 +4,17 @@
 
 An http2 server
 
+### Change Wishlist
+- Use the tls-api so that Osmium users can choose their tls implementation. At the moment Osmium is completely tied to OpenSSL. 
+    + Waiting for tls-api to be implemented by the Rust developers.
+- Connection shutdown currently requires the use of a boolean flag to guard against new frames being queued for processing and queued promises having their execution initiated. It would be much cleaner to perform shutdown actions in the connection then use an exception to break the read/write loop. 
+    + Waiting for exceptions to be implemented in Rust, there's an RFC but nothing on stable yet.
+- Ability to run streams on seperate threads. Currently, each connection is assigned a thread and all connection and stream processing occur on that single thread.
+    + The number of connections should easily outgrow the number of threads the host has to offer. This means that the whole concurrency model has to change to make this work. The connections need to not hold onto a thread when they're innactive, so that the thread can be used by another connection. That or a lighweight threadpool needs to be used.
+    + Some intelligence needs to go into assigning resources to a connection. Probably the most logical way to go about this would be to implement priority, and use that as a best guess to decide when a connection can take advantage of concurrent streams vs a connection which is just making a lot of requests independently. A more sophisticated system than that would have to be both another wishlist item and priority would need to be seen to be more commonly used than it currently is.
+- Create a server administration tool that allows server/stream state to be viewed in real time with history etc. This is part of a more technical requirement that connections be made subject to administration by the main thread, so that suspected idle connections can be pinged and shutdown if necessary.
+- Setup benches to performance test the server, and test coverage to provide confidence. Both of these are difficult because of the slightly restrictive way that tests have to be run in rust. To do these properly a seperate process needs to be started for the server, but data can't be collected about the seperate process.
+
 ### Developer setup instructions
 
 - Make sure you have rustc 1.21 (or above)

src/http2/core/connection.rs

@@ -80,7 +80,7 @@ impl<'a> Connection<'a> {
             send_window: settings::INITIAL_FLOW_CONTROL_WINDOW_SIZE,
             receive_window: settings::INITIAL_FLOW_CONTROL_WINDOW_SIZE
         };
-        
+
         new_con.apply_settings(initial_settings, false);
 
         new_con
@@ -93,7 +93,6 @@ impl<'a> Connection<'a> {
     {
         log_conn_frame!("Receive frame", frame);
 
-        // TODO if rust adds exceptions, then this can be redone.
         // This is slightly untidy, and is essentially a side effect of not having exceptions in Rust. The read write loop in the
         // net code could be immediately terminated with an exception. As things stand, this is the cleanest way to handle shutdown.
         if self.shutdown_initiated {

src/http2/net/mod.rs

@@ -95,9 +95,6 @@ impl<T, R, S> Server<T, R, S>
 
         let server_instance = Arc::new(Box::new(self));
 
-        // TODO the code below means that all streams run on the same thread. Probably
-        // not the way it should be.
-
         // get a stream (infinite iterator) of incoming connections
         let server = listener.incoming().zip(stream::repeat(server_instance.clone())).for_each(|((socket, _remote_addr), server_instance)| {
             debug!("Starting connection on {}", _remote_addr);