Double-check clarity on some Finagle, SearchBird items

[lahosken]

I just watched @jdowens present about Finagle to TwitterFolks. They had some questions. The presentation wasn't the same material as Scala School, but questions can point out confusing topics. At some point I should take time to ponder these (and maybe turn some of them into their own individual issues). But I should at least note them down in an issue instead of in a little text file on my laptop:

• In Finagle design, why would you ever want to support RPCs methods other than HTTP-RESTful?
• If your service is a long-running thing, you might worry about:
  If your service is basically a filter and if your code thus "stops running" while waiting for the asynchronous stuff upstream from you to finish--do you need to worry that you'll get garbage-collected?
  (Involved question from same guy that I barely understood, but the answer was:) Use FuturePool
• Why does .map return a Future[thingy] instead of a thingy? You said "synchronous", doesn't that mean that the .map will block?
• The Future isBanned example would be better if there was some asynchrony in the isBanned function itself.
• Why do we humans have to choose between map and flatMap? Couldn't some Scala type-magic figure out to use flatMap if it sees nested Future types?
• We only showed a small part of the searchbird example, didn't show any exception handling. Folks wanted to know good place in which to "bump the error count".
• This timeout filter example: is this how all timeouts work in (some context)? Answer: no.
• If your service throws, does it throw then-and-there? Or does it wrap the exception in a Future and send it down the line?
• Example client, server say things like .name("excellentClient") What is that name used for?
• The .within example might be old?