What have you found for these years?

2011-09-01

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?

0 retries:

Post a Comment

All texts are licensed under CC Attribution 3.0