next step for rib and rest-core! (中文)

速記，所以寫中文，列一些接下來要做的事。

Rib:

* 首先是看來 rails 3.1 或是 rails 3 的 console 的讀取方式
並不完全就像是 ripl-rails 那樣。至少，看起來 rails 3.1 的
rails console 會把 SQL log 丟到 $stdout 上。

這應該不難修，只是又要看 rails source 很頭痛而已。
可能晚點就修掉吧，感謝 tka 的告知。

* 就像我丟到 issue tracker 上的 Don't rely on require order!

https://github.com/godfat/rib/commit/7a97441afeecae80f5493f4e8a4a6ba3044e2c33

So here we have a problem. Some plugins are expecting to override
some other plugins. The order can't really be arbitrary.....
Actually, users won't care about order either. We just want to
enable/disable plugins, not really composability.

So it really should be a bucket of plugins. At least for built-in plugins,
so that we would be aware of the order. Users shouldn't pay attention
on the order of built-in plugins.

不過這個沒那麼容易處理，我還在想要怎麼做比較好。相關的問題是，
要不要像 rack 一樣，把 stack 太深的問題一起處理掉？畢竟現在這種
作法，會跟 rack 一樣，如果 plugins 用太多的話，會導致 call stack 變得
很深。

一個可能的想法是，plugins 會放在一個 list 中，然後他們也都有一個
dummy parent, 使得原本很簡單的 overriding 的方式還可以繼續用。
不過實際上可能沒那麼單純，沒辦法做成這樣。畢竟重點在於，如果是
一個 blocking call 的話，那勢必會用掉 stack frames. 在 rack 裡，
還能很簡單地用 before 或是 after 來處理，但 rib 裡面那麼多 API,
難道要每個都加入個 before/after? 這樣會讓寫 plugin 的成本變得高很多。

* 總之，stack frames 還不算大問題吧，重點是要處理掉 require order 的
問題。在 rack 或 rest-core 中，順序還是重要的，意思不同。但是在 rib 中，
通常我們只會希望有個功能有或沒有而已，至少，內建的 plugins 是這樣！

而在處理這個的過程中，如果可以一併處理 stack frames 的問題則處理，
不能的話就當另一個問題，再考慮到底值不值得去換這個好處。

rest-core:

* 目前 twitter client 還沒有分析 return error, 可能翻翻 twitter gem 或是
Error Codes & Responses 來看看怎麼做比較好吧。這是花時間沒難度的。

* 然後是把 rest-graph 的 RailsUtil 和 TestUtil 搬過來。這個.. 算是苦工？
不過重點在於，到底該怎麼安排？放在 rest-core/util/ 底下嗎？ dependency
怎麼處理？user 應該怎麼使用？要手動 require, 還是自動 require?
test 要怎麼跑？等等。

* 接著相關的是，要把 RestGraph 改名為 Facebook. 只改名字自然是很容易，
但接下來的問題則是，現在完全針對 RestGraph 寫的 test 該如何調整？
有些 tests 其實是對任意 client 都適用，但有些是針對 rest-graph.
要怎麼安排這些 test? 現在的狀況是，跟 rest-graph 的 test 是一模一樣的。
這樣做的原因是，我希望原本的使用方式，在 rest-core 裡面都能繼續用。
事實證明，這種作法確實抓到不少我原本沒想到的 bugs. 都修好啦。不過
也因此使得程式內部實作十分複雜就是了。邊寫邊覺得原來原本是這麼複雜...

這個應該算苦工吧。調整 tests 是十分痛苦的差事.... 要拆掉我自己原本花了
很多時間做的 tests 也很令人難過 ><

* 同上面 rib 那邊提到的，既然 rack 會有的問題，在 rest-core 裡當然也有。
用一個 list of middlewares 加上 before/after 和原本的 call 應該可以
有機會可以解決 stack 太深的問題。這邊應該會比 rib 好處理很多...

* asynchrony call? 原本 rest-graph 本身是有支援 em-http-request,
這邊要怎麼處理？其實這跟上個問題是相關的。evented 的世界本身就不是
用 stack 去組織流程的，因此解決了上面的問題，evented 的問題應該也
解決了吧？或是先讓 block 成為 callback 也可以。這個問題應該比上面的
問題要來得容易，不過由於上面解決了這個也解決了，因此放在下面。

另外，如果要用 fiber 的話，應該是不用調整架構吧。

* twitter 的 RailsUtil?