fastcgi-client-rs

fastcgi-client-rs copied to clipboard

Hi,

I'm shopping around for a fastcgi crate and after reading the code, I had a couple of questions, if you have time to look at them:

• it looks like requests are only executed one at a time (Client.execute() takes a &mut self, and keeps it until the response is fully processed), is my understanding correct?
• if so, it's probably not necessary to keep a hashmap of ids, since only one is ever used (but to be fair, I'd rather have concurrent requests)
• Client.request_id_generator fields don't need to be mutexed since the struct is only accessed via Client's methods using &mut self
• Client.inner_execute() could avoid cloning I believe as the response is never (or should never) be updated once it has been returned to the caller
• the getter/setter approach to Responsefeels weird as it's never updated once returned to the user, so the std* could just be public

I might we wrong on some/all of those, as I only skimmed the code and haven't thoroughly tested it, apologies if I drew the wrong conclusions.

I'd be happy to open PRs to address some or all of these if you are open to it.

1. Because the fastcgi protocol optionally supports keepalive, there should be two kinds of clients, namely Client and KeepaliveClient, and the execute methods are Client::execute(self, ...) and KeepaliveClient::execute(&self) , ...), the former can only be executed once, while the latter can be executed multiple times concurrently (or is there a better api design?). And now I just pass keepalive as a bool parameter in Client::new, which is a lazy approach.
2. In keepalive mode, the generated request id is released after the requst is completed, so I use a HashSet to save the requst id to prevent the generated request id from being repeated. Maybe there is a better performance.
3. Other issues are performance and api design issues, which I think can be changed.

PRs are welcome.

With 0.8.0-alpha.1 released, 1, 2 solved.