十五年前，前輩先進們討論著 BBS 的未來。

maple_future_0.txt

 作者  Thor (淡出)                                          看板  plan
 標題  Maple未來發展
 時間  Fri Jul 24 09:47:41 1998
───────────────────────────────────────

只是隨便取個聳動的標題而已:ppp

現在 bbtpd.c opus還沒寫完就消失了,
我在想直接接下去寫會不會對他大不敬呀?:P

然後那個寫client的最近又不知道在忙什麼,
弄個chat client之後也消失了:pp

我有個想法, 想用 browser上maple bbs,
就是作得像 nsysu那個樣子, 不過是用 java applet + html 來作
這樣有個好處就是, 用browser還可以被扣/扣別人熱訊(這是什麼動機...:p)
以及 talk/chat, 不過前一陣子有問過中山的webbbs使用狀況,
似乎使用率不高, 所以作罷..

不過還是很期待有一天maple能像 galaxy, nsysu一樣, 進站就看到漂漂的畫面,
還有地圖可以給人家點, 漂亮的風景給人家看.....

最後, 這篇只是純灌水的文章, 版主看了不爽就刪吧...呵呵呵:P
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: skynet.cs.nthu.edu.tw

maple_future_1.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Tue Jul 28 07:16:14 1998
───────────────────────────────────────

※ 引述《Thor (淡出)》之銘言：
> 我有個想法, 想用 browser上maple bbs,
> 就是作得像 nsysu那個樣子, 不過是用 java applet + html 來作
> 這樣有個好處就是, 用browser還可以被扣/扣別人熱訊(這是什麼動機...:p)
> 以及 talk/chat, 不過前一陣子有問過中山的webbbs使用狀況,
> 似乎使用率不高, 所以作罷..
> 不過還是很期待有一天maple能像 galaxy, nsysu一樣, 進站就看到漂漂的畫面,
> 還有地圖可以給人家點, 漂亮的風景給人家看.....
> 最後, 這篇只是純灌水的文章, 版主看了不爽就刪吧...呵呵呵:P

  我也是純灌水... 畢業了, 等當兵提不起勁來改／寫東西...
  (btw, 程式能力還是 @#%$%$%)  反正當玩兵回來也沒得玩了
  就把一些想法拿出來討論一下好了.

  關於 web-bbs , 大概是我大二... 今年大五, 三年多前就想
  過(1994-1995, 夠早了吧 :P ), 不過當時時機不好, 不過初
  步可以把整個精華區轉換成 html , 再透過 httpd 由 browser
  讀取.

  後來學了點 cgi , 就做出 prototype , 可以透過這個方式
  完成 bbs 除了 "即時" 的功能, 如 chat/talk/msg 之外,
  如 mail 和 board 的 read/write 和 user login/logout
  的處理. 後來也有寫出 java chat (另外的 chat server,
  現在也有人寫了可以跟 xchatd 連接的 java chat 了吧)

  雖然後來也沒什麼成果, 雖然已經接近可用狀態了, 不過
  剛好大三下出去實習, 又全都放下了, 後來也沒有再去發
  展這個東西, 因為已經有很多使用 cgi 的 web-bbs 出現
  (嚴格來說, 應該是獨立的 web-board 跟 bbs 沒什麼關係)
  再發展下去好像沒什麼搞頭. :P
  不過在這個過程中, 也累積了一些關於 web-bbs 經驗.
  也寫了一堆自稱為 web-bbs cgi libary 的程式, 以現在
  的眼光看來, 亂像是垃圾的. <grin>
  這裡面包含了 user 登入程序 / 在每一個連線的認證 /
  ANSI TEXT -> html text (處理顏色/閃爍) 等等...

  其實到現在為止, 有很多 web-bbs / web-board 都沒辦法
  有效的防止 reply attack , 尤其是以 cgi 為基礎的.
  甚至如果有人在你用過的電腦裡挖出你的 cahce , 就可以
  不需要你的密碼直接登入, 這是很好笑的事情. :(

  不過在實習的時候又另外學了新招, 使用 server side
  scripting 可以達到一堆 cgi 做不到的事情, 效能也好
  的多, 對於 bbs 和 web 放在一起的環境下, 應該是很
  有利的. 或者可以使用 apache 的模組來作這個事情.
  因為 cgi 有 cgi 做不到的事情, 例如操作 cookie .
  server side script 就可以 , 這個對於解決一些
  資料往復傳送的問題有很大的幫助.

  後來人閒下來, 想的東西就多了.
  bbs 最怕的是什麼? 一堆 disk i/o , process 起起落落
  和一堆 connection ( syn attack? tcp storm? )

  用 cgi 應該是 load 最中了, 用 server side script
  或是模組都無法減少 disk i/o 和 process 起起落落的狀況
  但是以 web bbs 的觀點來看, 我們根本不需要支援完整的
  HTTP ...


--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: W4.mis.yzu.edu.tw

maple_future_10.txt

 作者  rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？) 看板  plan
 標題  Re: Maple未來發展
 時間  從零開始 (Wed Aug  5 02:12:59 1998)
 路徑  maple!news.cs.nthu!fromzero
 來源  freebsd.ee.ntu.edu.tw
───────────────────────────────────────

※ 引述《lasehu.bbs@bbs.cs.nthu.edu.tw (lasehu)》之銘言：
: ※ 引述《rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？)》之銘言：
: >     這應該可以自己加幾行做點小記錄吧。 :P
:   加幾行?? oh... 願聞其詳 :)
:   web 的入口可能有很多, 除非強迫 user 由單一入口進入,
:   否則沒辦法統計 daily logins. 頂多就是做到像 counter.cgi
:   計算某頁的 visit 人數!
:   當然還是可以算大約值, 不過大約到哪種程度就難說了 :)

    web 的入口很多是沒錯啦，但是如果有類似 login 的動作，
    總該是可以留下記錄的，除非是完全不考慮這方面，大家都
    是 guest :Q

    另外一個著眼點就是找出對方是從哪裡連過來的，就算透過
    proxy 還是可以找出是哪台機器在觀看，約略統計一下有多
    少不同的 host 在觀看，也可以約略估計出族群的大小吧。

maple_future_11.txt

 作者  Xshadow (小叉影~~)                                   看板  plan
 標題  Re: Maple未來發展
 時間  Wed Aug  5 16:07:04 1998
───────────────────────────────────────

※ 引述《rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？)》之銘言：
> ※ 引述《lasehu.bbs@bbs.cs.nthu.edu.tw (lasehu)》之銘言：
> :    對很多使用者來說, 上網路大概只有 browser 或是 xx 網站:)
> :    talk/chat 不是沒有做, 只少中山web-bbs用 activex 寫過talk componet
> :    chat 則是用 mschat, 所以 browser 非得用 MSIE. 印像中 yzu 的 ice
> :    web-bbs 應該是 netscape required :)
>      那還不如 telnet 的跨平台。 :P

       是呀, 小旭旭講到重點了, 目前 web-bbs 推廣的困難之一, 還是在於
       browser 本身。browser 處處可見, 快變成最基本的 Application 了,
       但往往實在出來的 web-based 系統, 卻還是標明著, "Netscape 4.0
       or later only", "MSIE 4.0 or later only", 這算哪門子的方便呢 ? :(

       現在大家積極往 web-based 方向走, 但我仍有一個疑問, 一個目前不會
       有解答的問題："日後, 經歷 web 已可以初分發展的時間後, 將會是如同
       許多 Web 狂熱者的想法般, everything except OS runs on Java enabled
       browser 呢 ? 還是如同目前一般, 該是以 native application 型式存
       在的軟體仍然存在, 只不過搬進 browser 的軟體數量比例上變多了 ?"

       許多軟體, 我仍感覺不到搬進 browser 的好處, 只是流行一句話罷！？
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: dial4-150.Eden.nthu.edu.tw

maple_future_12.txt

 作者  lasehu (lasehu)                                      看板  plan
 標題  Re: Maple未來發展
 時間  Thu Aug  6 03:34:33 1998
───────────────────────────────────────

※ 引述《rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？)》之銘言：
> :    其實用 www 界面主要的好處是 browser 到處都有 :)
>      也是啦！不過我是不會去用那個上線，感覺很難用。 :P

  我也是做如此想! 蠻矛盾的, 一個連系統開發者本身都不想用的系統,
  要指望 user 愛用它 ? :)

> :    rexchen 對 talk/chat 有甚麼好的做法或是 idea 嗎?
>      基本上對這問題，我能想到的除了 java 之外，還是 java :Q

  java... 真是殊途同歸呀. 曾經用 active 寫過 talk component
  連 client-server based bbs system, 借用 c/s bbs 的系統,
  把 talk component 擺進 browser, 不過 MSIE required.

  不知你的 java talk 是否已有雛形?

--
Dept. CIE. Natl. Sun Yan-sen Univ.




--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: cc.nsysu.edu.tw

maple_future_13.txt

 作者  lasehu (lasehu)                                      看板  plan
 標題  Re: Maple未來發展
 時間  Thu Aug  6 03:40:55 1998
───────────────────────────────────────

※ 引述《Xshadow (小叉影~~)》之銘言：
>        browser 本身。browser 處處可見, 快變成最基本的 Application 了,
>        但往往實在出來的 web-based 系統, 卻還是標明著, "Netscape 4.0
>        or later only", "MSIE 4.0 or later only", 這算哪門子的方便呢 ? :(

  唉... 有罪的是程式設計者嗎? 是 Browser 廠商嗎? :)
  Netscape 或是 MSIE 連自己的各家版本有些 page 能正常 work,
  有些不能... 你說呢? :) 舉個例子, 中山 web-bbs 的首頁,
  因為使用者所採用的 Netscape browser 版本不同, 所以得寫
  好幾個版本的 page.

>        現在大家積極往 web-based 方向走, 但我仍有一個疑問, 一個目前不會
>        有解答的問題："日後, 經歷 web 已可以初分發展的時間後, 將會是如同
>        許多軟體, 我仍感覺不到搬進 browser 的好處, 只是流行一句話罷！？

  不單單只是流行, 可以思考一下, 為甚麼 browser 會流行...
  就可以知道為甚大家要往 browser 或是 java 上走 :)


--
Dept. CIE. Natl. Sun Yan-sen Univ.




--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: cc.nsysu.edu.tw

maple_future_14.txt

 作者  Xshadow (小叉影~~)                                   看板  plan
 標題  Re: Maple未來發展
 時間  Thu Aug  6 10:38:17 1998
───────────────────────────────────────

※ 引述《lasehu (lasehu)》之銘言：
> ※ 引述《Xshadow (小叉影~~)》之銘言：
> >        browser 本身。browser 處處可見, 快變成最基本的 Application 了,
> >        但往往實在出來的 web-based 系統, 卻還是標明著, "Netscape 4.0
> >        or later only", "MSIE 4.0 or later only", 這算哪門子的方便呢 ? :(
>   唉... 有罪的是程式設計者嗎? 是 Browser 廠商嗎? :)

    不能說有罪, 只是當初在決定移植到 browser 身上前, 就應先考量所帶來的
    利敝得失, 而不是一味 web 化, 在我看來, PM 的"罪"較重。:p

>   Netscape 或是 MSIE 連自己的各家版本有些 page 能正常 work,
>   有些不能... 你說呢? :)

    對, browser 爛是他們自家的事, 實在難用 :)
    不過 programmer 的要旨在於提供 end-user 一個舒適單純便利的使用環境,
    任何使用者不便都不該也不能有任何理由任何藉口, 若目前的 browser 還太
    爛, 不適任在其上發展程式, 那就是 programmer 本身的責任, 不該在未成熟
    的環境下發展軟體, 而告訴使用者說, "這是因為 xxx 牌 ooo 瀏覽器的問題"
    等等 ..

>   舉個例子, 中山 web-bbs 的首頁,
>   因為使用者所採用的 Netscape browser 版本不同, 所以得寫
>   好幾個版本的 page.

    目前比較完善, 專業一點的商業網站都是這樣做的, 例如我看過一套是
    分別用 CGI, ASP, JavaScript 及 JScript 應付 [MSIE|Netscape] [3.x|4.x]
    的網站, 辛苦的很。目前的 web-programming 似乎還很多的時間都花在無謂
    的 work-around, 對 user, 對 programmer 都不算是百利而無一敝。

> >        現在大家積極往 web-based 方向走, 但我仍有一個疑問, 一個目前不會
> >        有解答的問題："日後, 經歷 web 已可以初分發展的時間後, 將會是如同
> >        許多軟體, 我仍感覺不到搬進 browser 的好處, 只是流行一句話罷！？
>   不單單只是流行, 可以思考一下, 為甚麼 browser 會流行...

    Because, browser is exist everywhere.

>   就可以知道為甚大家要往 browser 或是 java 上走 :)

    從另一面想, native application 會消失嗎 ? ;)
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: dial4-153.Eden.nthu.edu.tw

maple_future_15.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Sat Aug  8 22:42:32 1998
───────────────────────────────────────


The Daemon

它必須是 single daemon , 因為一個真正的 web-bbs 不允許製造
太多的 process , 以避免 process 起起落落的問題. 這麼一來,
我們能夠選擇的方式就不太多了.

我能想到的有三種, 第一種就是採用輪流服務的方式, 這種方式在
實作上應該是比較簡單的, 不過有一點可能需要特別注意, 如果一
個 request 在處理的期間需要等待(如檔案被鎖定等等)有可能造成
這個 "輪流服務"的機制發生一點問題, 而造成所有的 client 都一
起等待.

第二種是採用 multi thread 的方式, 每一個接進來的 request 都
creat 一個 thread 去執行, 這樣的設計需要較高的程式技巧, 不
過不會"卡住", 不過是不是適合於任何一種 bbs 執行的平台上使用
就不知道了, 因為這需要作業系統的支持 multi thread.

第三種有點像兩種方式的綜合, 以一個 daemon 先 queue 住 request
, 然後有其他的 process 去處裡, 每個 process 在處理完一個
request 之後, 再從 daemon 的 queue 中取一個 request 來處理.
這種方式在程式的撰寫上可能更加麻煩, 但是彈性更大, 在一些很大
型的場合經常運用這種設計. 當我們想要增加它的處理速度時, 只要
增加 process 的數量. 而單一的process 處理異常, 也不會影響到整
個系統的運行. 不過, 這個在bbs的服務尚未分散之前, 能得到的好處
並不多. 簡單的說, 這些其他的process 可以在其他的機器上執行,但
是除非它所需要的資源是分散在其他的機器, 否則 load 還是會回到
bbs 的主機.

因此個人認為第二種方式可能是目前比較好的設計方式.


Processing The Request

我們不需要支持完整的 HTTP , 而只需要處理基本的兩種 request 型態
"GET" 和 "POST", 其餘的特別支援應該是不需要的(PUT ?), 畢竟我們
是要一個 web-bbs. 不過我們可以將他們視為等位, 因為他們的回應都是
一個 html 的頁面.

為了特別去適應那種 keyword 系統, 我們可以在處理一個 request 的時
候(不論它是 GET method 還是 POST method ) 先整理起來成為 request(*)
物件 (概念上, 實行上可以是 char** 或是在另外用一個方式去取用.)
使得處理 keyword 的部分程式, 可以簡單的知道它應該處理的一些參數.

同時, 這個步驟還需要去處理驗證 SESSION KEY , 確認有這一筆登入記錄.
並且要找出相對應的 user data (相當於 UTMP) , 在處理 keyword 時, 這
也是一個必要的參數. 當一切就緒, 就可以開始輸出 html 了.

為了避免過多的 Disk I/O 這些將會被讀取的 html 應該可以被放在記憶體
中. 我們可以預期這些含有關鍵字的 html 檔案不會太大. 放在記憶體中,
應該不會造成太大的負擔.

輸出的時候, 對照一個關鍵字表, 當 html 的內容出現這個關鍵字時, 就呼叫
相對應的函數, 並且將 client(*) (ps. 是 user data) 和 request(*) 傳給
它, 它將會輸出一些特別的 html 內容, 完了, 再回到這裡繼續.

為了能夠方便新增一個關鍵字, 我希望關鍵字表會是一個簡單的 table, 就是
列出關鍵字, 和它對應的函數. 這樣使得後續的發展者可以很容易的增加一個
關鍵字, 就可以使得 web-bbs 可以有更多的功能. (如M3一樣)


The Keyword

Keyword 出現的形式可以像這個樣子:

<%BOARDLIST(LINK=atricle_list.html, LISTITEMS=20)>

或是

<%BOARDLIST>
LINK=article_list.html
LISTITEMS=20
</%BOARDLIST>

或是

<WEBBBS>
ACTION=BOARDLIST
balabala ....
</WEBBBS>

個人其實比較喜歡第一種形式, 不過其實作用都是一樣, 只要能夠
方便的從 html 中篩檢出我們的關鍵字, 並且接受它的參數就行了.
另外一個重點是, 要讓 "人" 可以容易撰寫.

再接下來, 除了 html 中 embeded parameter 之外, keyword 處理
還需要將 GET method 的 URL encode 以及 POST method 傳入的資
料, 通通都收進來. 因為我們可能還會處理到像是:

GET /bala/atricle_list.html?LIST=NEXT

或是

<FORM ACTION=atricle_list.html METHOD=POST>
<INPUT NAME=LIST VALUE=NEXT ... >
balabala
</FORM>

預先整理, 劃一的輸入方式, 可以使得後來的發展者更容易發展新功能.

--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: std1.mis.yzu.edu.tw

maple_future_16.txt

 作者  yklps (vision)                                       看板  plan
 標題  Re: Maple未來發展
 時間  Tue Aug 11 00:13:26 1998
───────────────────────────────────────

※ 引述《gc (溫柔的刀)》之銘言：
> Processing The Request
> 我們不需要支持完整的 HTTP , 而只需要處理基本的兩種 request 型態
> "GET" 和 "POST", 其餘的特別支援應該是不需要的(PUT ?), 畢竟我們
> 是要一個 web-bbs. 不過我們可以將他們視為等位, 因為他們的回應都是
> 一個 html 的頁面.

除非這個自己手工打造的HTTPD SERVER效能和APACHE很接近，
那麼使用這種方式倒無妨，

若是效能差很多，那麼您會發現這樣做會有很多後續不少棘手的問題
很難處理，花了很大功夫，但是效益增加很少，甚至是開倒車.....
就算自己寫的HTTPD SERVER目前效能不錯，但是一遇到新的HTTPD PROTOCOL
您會發現虧大了，一堆難以彌補的問題馬上浮現........

而且APACHE本身功能很齊全，用起來會讓系統如虎添翼，
並且APACHE還有很多現成的模組可以用，不同系統的可攜性又是一流，
絕對讓你不得不考慮

--------------------------
Welcome to Galaxy BBS:  http://www.galaxybbs.com
--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: h18.s189.ts.hinet.net

maple_future_17.txt

 作者  qing (Qing)                                          看板  plan
 標題  Re: Maple未來發展
 時間  Wed Aug 12 08:14:22 1998
───────────────────────────────────────

※ 引述《gc (溫柔的刀)》之銘言：
> 個人其實比較喜歡第一種形式, 不過其實作用都是一樣, 只要能夠
> 方便的從 html 中篩檢出我們的關鍵字, 並且接受它的參數就行了.
> 另外一個重點是, 要讓 "人" 可以容易撰寫.
> 預先整理, 劃一的輸入方式, 可以使得後來的發展者更容易發展新功能.

    你說的這種架構跟我去年寫的差不多, 我在 Solaris ( 也 port 一份
    到 Win32 上) 做的差不多是如此. 用 multi-thread 的方式, HTTPD
    產生的 text/html 可以套用一個具有變數代換的 template 來產生.
    身份認證的部份可利用 HTTP protocol 內建的 Authorization header
    , 當 Browser 收到 404 response code 時, 會自動的詢問 user id
    和 password, 此後的每一次 HTTP 的訊息交換都會把 Authorization
    header 加進去, 當 browser 關閉之後, 此資訊將會消失. HTTPD 收
    到 request 之後, 可根據此一 header 做身份的確認.
    這種型態的 server 好處在於 module 和 module 之間的聚合力提高,
    因為都在同一個 process 裡頭, data 本來就是共享, 只需要注意一
    些同步的問題即可. 在不同的 CGI 程式之間要彼此交換訊息, 可能
    就要透過一些較為複雜的機制.
    
    但是自己手工打造的 HTTPD 在穩定度上要和 Apache 相比, 可能....

--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: alpha1.cs.nthu.edu.tw

maple_future_18.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Sun Aug 16 03:45:38 1998
───────────────────────────────────────


The Concept

以 web-bbs 來說, 除了動態的應用如 talk , chat , write 之外, 大
部分的應用都是讀取檔案而已, 因此這個關鍵字系統也是依照這個目的
來設計. 這個設計應該可以滿足大部分的應用了. 當然, 這都是在 bbs
修改需求最小的前提之下.

我依照下面幾個原則去構思這個設計:

1.滿足"適合與現行 bbs 結合".
  為了目前適應 bbs 的環境, 它是 single daemon, 耗用較少的記憶體
  且運算需求不高. 在 bbs 主機上執行的 web-bbs 可以直接去存取 bbs
  的 shm . 捨棄彈性更大的 scripting 以節省運算與 I/O 需求. 以一個
  特別設計的 daemon 去管理資源, 可以得到較好的效果.

2.介面的修改要簡單(去除 daemon 與界面設計的相關性).
  一般的 bbs 架站者, 除了一些知名的發展者之外, 很少對 bbs 的程式
  碼做重大的變更. 通常只是修改介面使得 bbs 能夠更方便好用. 將介面
  (html碼) 獨立出來, 便是要達成這個目的. 這又有另外附帶的好處, 除
  了原始發展者測試所要用的 html 之外, 整個介面可以很輕易的重新被設
  計. 設計方便好用的介面, 變成其他要應用 web-bbs 的站長們的工作.

  btw, 這裡可以有個很有趣的應用, 這種設計的 web-bbs 可以很輕易的
  變換 "皮膚" . 如同 winamp 更換 skin 一樣. 也許以後會有人專門在
  這上面發展不同的 skin .  :P

3.保持足夠的彈性給"界面設計者".
  因此關鍵字系統的輸出必須可以達到一定程度的 customize , 而且介面
  設計者不見得對 daemon 的設計有非常深入的了解.
  滿足前者則必須使關鍵字系統可以輸入一些參數, 滿足後者則要有一個固
  定的格式給這些界面設計者使用, 並且要有足夠的方便與彈性, 所以基本
  的 url encode 和 POST method 都要支援到, 而且設定方式要夠簡單.
  因此參數的設定用 keyword = value 應該是最容易接受的了. (與 html
  相似, 因為介面本身就是以 html 撰寫).

4.預留平行與次級發展者的空間(將通訊機能與服務機能分開).
  一個 daemon 內部的關鍵字列表是有必要的, 而後續的發展者對於尚未提
  供的或是自行發展的 bbs 特別功能, 可以就簡單的撰寫一個 function 加
  入到這個列表中, 就可以使用自行發展的功能, 而不需要對這個 daemon
  的其他部分做深入的了解. 這可以使得 web-bbs 的發展更加容易.
  強烈建議: 將每個關鍵字的原始碼打散到同名的檔案中, 如此一來當其他
  發展者相同功能的關鍵字時, 只需要複製一個檔案, 並加入到關鍵字表中
  即可.






--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: std1.mis.yzu.edu.tw

maple_future_2.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Wed Jul 29 16:53:01 1998
───────────────────────────────────────


  傳統式做法(CGI)的問題

  製作 web-bbs 最直覺的做法就是撰寫 cgi 程式, 將 bbs 上的檔案資料
  轉換成 html 形式, 以供 browsers 閱讀. 而 bbs 上的檔案 mail/post
  甚至精華區, 都有隨時會變動的特性. 所以也沒辦法先轉成靜態的 html
  檔案, 所以在每次讀取頁面的時候, 都會 fork 一次 httpd, 然後又一次
  的執行 cgi 程式. (load)

  再者, 如果要提供使用者 post 和閱讀個人 mail 的話, 一定得有使用者
  的帳號認證, 這個做起來頗為簡單, 只要去抓 .PASSWDS ( or ACCT on
  Maple 3 ) 裡面的 crypted passwd 字串和 user post 回來的 plan
  text passwd 去做 crypt 就行了, 我們可以很輕鬆的去做密碼比對的工
  作, 但是在接下的動作就有問題了...

  http 與 telnet 有個基本的不同, telnet 是一個持續的 tcp connection
  但 http 可能同時有很個 request , 而且並不一定是連續的. ( 即使是
  Keep-alive 也不算, 那只減少 process 起起落落的問題而已)
  那麼為了使 user 不會在每一個動作都需要輸入密碼, 那麼是必要在 html
  中塞進一個識別的字串, 當 browser access 時會傳回來以證明它是合法
  的存取動作. 不論使用 post method 或是 get method 這些字串必然在
  client 和 server 傳來傳去, 而 client side 所見到的 html 必然充斥
  著一大堆這種字串.

  那考慮一下, 如果我把我在 login 後把 html 存下來, 那麼下次存取的時
  候, 我不需要經過登入的程序就可以進行操作, 因為存檔的內容有我完整
  的登入資訊, server 上的 cgi 程式會認為我已經經過登入程序的認證了.
  如果這是我自己存檔的, 這也還好, 如果這是別人從我的 cahce 中挖出來
  的, 那就不好玩了.

  為了解決這個問題, server 上面也要有個記錄, 來證明的確有一筆我的登
  入記錄. 這可能是存個檔, 或是用 shm 等等的方式. 而且這個記錄必須要
  會過期, 就像 bbs idle 過久會自動斷線一樣. 那又需要另外一個程式去
  隨時去檢查這些記錄了.

  考慮如果我在一公用的電腦上線, 然後把 browser 關掉後離開(但沒有
  logout, 由 server 上的 cgi 移除我的登入記錄). 那下一個用這台電
  腦的人可以直接在打開 browser然後連上 web-bbs 的 url , 以我的身
  分繼續進行操作(可以從 cache 中把辨識字串挖出來). 這也不好玩.
  
  那何不用 hhtp auth 的方法? cgi 好像沒辦法做, 要隨時去轉換 .htaccess
  又太過麻煩, load ...

  即使這個問題被解決了(還很簡單), 但是在回想一下, 這樣的做法除了
  增加很多 process 起落的機會, 又增加了 Disk I/O ... 這樣的做法也
  許還是可行的, 但是過多的 process 和 I/O 使它不適合在 load 本來
  就很重的 bbs 上面執行.


  btw, 有心發展 web-bbs 的人可以依照這個方向, 去測試一下目前現有的
  cgi based web boards . 有很多這類因為認證的問題所引發的 "不好玩"
  的狀況.


--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: W4.mis.yzu.edu.tw

maple_future_3.txt

 作者  edwardc.bbs@Jong.GradDorm2.nctu.edu.tw (小甜甜),     看板  plan
 標題  Re: Maple未來發展
 時間  Coba BBS (Fri Jul 31 01:07:04 1998)
 路徑  maple!news.cs.nthu!JCPP
 來源  coba.graddorm2.nctu.edu.tw
───────────────────────────────────────

【 在 gc.bbs@bbs.cs.nthu.edu.tw (溫柔的刀) 的大作中提到: 】
:   傳統式做法(CGI)的問題
<咖擦>
:   那考慮一下, 如果我把我在 login 後把 html 存下來, 那麼下次存取的時
:   候, 我不需要經過登入的程序就可以進行操作, 因為存檔的內容有我完整
:   的登入資訊, server 上的 cgi 程式會認為我已經經過登入程序的認證了.
:   如果這是我自己存檔的, 這也還好, 如果這是別人從我的 cahce 中挖出來
:   的, 那就不好玩了.
:   為了解決這個問題, server 上面也要有個記錄, 來證明的確有一筆我的登
:   入記錄. 這可能是存個檔, 或是用 shm 等等的方式. 而且這個記錄必須要
:   會過期, 就像 bbs idle 過久會自動斷線一樣. 那又需要另外一個程式去
:   隨時去檢查這些記錄了.

        其實可以用這樣的做法, 多個 time stamp

        在登錄的時候, 產生一個 time stamp, 最好還可以編碼起來, 以免一些
        好奇的 user 給你改一改就不知道會發生啥事情

        然後身份確認過後這個 time stamp 就可以這樣 '傳宗街代'傳給接下來的
        cgi, 可以用來確認是不是把 url 給 mark 起來用的

:   考慮如果我在一公用的電腦上線, 然後把 browser 關掉後離開(但沒有
:   logout, 由 server 上的 cgi 移除我的登入記錄). 那下一個用這台電
:   腦的人可以直接在打開 browser然後連上 web-bbs 的 url , 以我的身
:   分繼續進行操作(可以從 cache 中把辨識字串挖出來). 這也不好玩.

        啊, 紀錄來源啊 :>

:   那何不用 hhtp auth 的方法? cgi 好像沒辦法做, 要隨時去轉換 .htaccess
:   又太過麻煩, load ...

        telnetd, fingerd 都在改了, 改改 httpd 改成跑 shm 應該可以吧

:   即使這個問題被解決了(還很簡單), 但是在回想一下, 這樣的做法除了
:   增加很多 process 起落的機會, 又增加了 Disk I/O ... 這樣的做法也
:   許還是可行的, 但是過多的 process 和 I/O 使它不適合在 load 本來
:   就很重的 bbs 上面執行.
:   btw, 有心發展 web-bbs 的人可以依照這個方向, 去測試一下目前現有的
:   cgi based web boards . 有很多這類因為認證的問題所引發的 "不好玩"
:   的狀況.

        認證問題對於 web-bbs 真的是不簡單, 因為有太多種可能, 太多種 "玩法"


--
※ 來源:‧第一靠邊站  king.ee.nctu.edu.tw‧[FROM: sun6.wfc.edu.tw]

maple_future_4.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Thu Jul 30 18:09:04 1998
───────────────────────────────────────

※ 引述《edwardc.bbs@Jong.GradDorm2.nctu.edu.tw (小甜甜)》之銘言：
> 【 在 gc.bbs@bbs.cs.nthu.edu.tw (溫柔的刀) 的大作中提到: 】
> :   隨時去檢查這些記錄了.
>         其實可以用這樣的做法, 多個 time stamp
>         在登錄的時候, 產生一個 time stamp, 最好還可以編碼起來, 以免一些
>         好奇的 user 給你改一改就不知道會發生啥事情
>         然後身份確認過後這個 time stamp 就可以這樣 '傳宗街代'傳給接下來的
>         cgi, 可以用來確認是不是把 url 給 mark 起來用的

  確認過後的 timestamp 傳回來之後, 在新的頁面還需要產生新的 timestamp.
  這個必須隨時更新, 而且需要來回的被傳遞...

  那麼這個 timestamp 或是任何其他的辨識字串, 必須有非常小的 size .

  原因是如果你要來回傳遞的話, 這個 timestamp 必然被包含在 html 中.
  考慮人機界面的話, 我們不希望使得操作複雜, 因此很有可能是使用單鍵
  操作而不用 <select> 和 <radio> 的方式, 在同一個頁面中會有很多個
  link (例如一頁有二十個看板列表), 那麼這個 timestamp 勢必要在 html
  中重複出現很多次...

  而在這很小的空間中, 它又必須容納足夠多的資訊. 這個就是為什麼需要
  在 Server 端保留記錄的原因. 要使得必須來回傳遞的資訊減到最小...
  除非的頻寬真的很充足. 不然來回傳遞的成本是很需要考慮的.

  這裡提到我遇到的一個瓶頸: 我需要一種適合小量資料壓縮與編碼的
  技術, 可惜對資料壓縮和密碼學的研究實在是不夠... :(

> :   考慮如果我在一公用的電腦上線, 然後把 browser 關掉後離開(但沒有
> :   logout, 由 server 上的 cgi 移除我的登入記錄). 那下一個用這台電
> :   腦的人可以直接在打開 browser然後連上 web-bbs 的 url , 以我的身
> :   分繼續進行操作(可以從 cache 中把辨識字串挖出來). 這也不好玩.
>         啊, 紀錄來源啊 :>

  登入的資訊當然要包含, 時間, 地點等等... 但是這邊還沒提到通過 proxy
  的狀況...

> :   那何不用 hhtp auth 的方法? cgi 好像沒辦法做, 要隨時去轉換 .htaccess
> :   又太過麻煩, load ...
>         telnetd, fingerd 都在改了, 改改 httpd 改成跑 shm 應該可以吧

　也是行, 不過有更好的做法, CGI based design 我認為是應該被捨棄了. :)
  例如使用 apache 的模組和 server side scripting . 都比 CGI 好多了.

> :   即使這個問題被解決了(還很簡單), 但是在回想一下, 這樣的做法除了
> :   增加很多 process 起落的機會, 又增加了 Disk I/O ... 這樣的做法也
> :   許還是可行的, 但是過多的 process 和 I/O 使它不適合在 load 本來
> :   就很重的 bbs 上面執行.
> :   btw, 有心發展 web-bbs 的人可以依照這個方向, 去測試一下目前現有的
> :   cgi based web boards . 有很多這類因為認證的問題所引發的 "不好玩"
> :   的狀況.
>         認證問題對於 web-bbs 真的是不簡單, 因為有太多種可能, 太多種 "玩法"

  別說對 web-bbs 了, 對 web 也是不簡單啊... :)

--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: W4.mis.yzu.edu.tw

maple_future_5.txt

 作者  Harimau.bbs@MSIA.pine.ncu.edu.tw ([松濤寶寶] 小虎),  看板  plan
 標題  Re: Maple未來發展
 時間  大馬同學會 大紅花的國度 (Sat Aug  1 15:15:30 1998)
 路徑  maple!news.cs.nthu!MSIA
 來源  msia.pine.ncu.edu.tw
───────────────────────────────────────

【 在 edwardc.bbs@Jong.GradDorm2.nctu.edu.tw (小甜甜) 的大作中提到: 】
: 【 在 gc.bbs@bbs.cs.nthu.edu.tw (溫柔的刀) 的大作中提到: 】
: : ※ 引述《edwardc.bbs@Jong.GradDorm2.nctu.edu.tw (小甜甜)》之銘言：
: :   單向編碼去包裝, 送回來再解, 反正 key 留在 server 端, 應該不會太容易...
: :   不過這個會使得資料量變大, 所以還需要壓縮的方法, 先壓縮, 再編碼, 應該
: :   會好一點... any way, 我們應該能夠想出更好的方法... :)
:         how about cookie ? 對 cookie 我不清楚
:         不知道 cookie 對於這方面應用有沒有方便的地方 :)


    何不考慮 Java 呢?

    http://MSIA.pine.ncu.edu.tw/~ppfoong/bbs/

    很久以前抓老外寫的 Java Telnet client 略改一改的, 還有很多問題沒
    解決, 也不太想去碰  :)

    Java 的好處是 applet 完全在 client 端跑, 所以 load 是用戶端的。
    Java 的缺點是: 啟始動作很慢...

--
◢□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■◣
□ 【 堅持信念 迎接挑戰 只向前永不倦  緊握信念 劃破黑暗 真摯誠會更光!! 】 ■
■   我是中央資工的 Harimau (小虎) http://MSIA.pine.ncu.edu.tw/~ppfoong   □
◥□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■◤

※ 來源:‧大紅花的國度 MSIA.pine.ncu.edu.tw‧[FROM: dragon.seed.net.tw]

maple_future_6.txt

 作者  rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？) 看板  plan
 標題  Re: Maple未來發展
 時間  從零開始 (Mon Aug  3 00:59:34 1998)
 路徑  maple!news.cs.nthu!fromzero
 來源  freebsd.ee.ntu.edu.tw
───────────────────────────────────────

※ 引述《lasehu.bbs@bbs.cs.nthu.edu.tw (lasehu)》之銘言：
: ※ 引述《Thor (淡出)》之銘言：
: > 就是作得像 nsysu那個樣子, 不過是用 java applet + html 來作
: > 這樣有個好處就是, 用browser還可以被扣/扣別人熱訊(這是什麼動機...:p)
: > 以及 talk/chat, 不過前一陣子有問過中山的webbbs使用狀況,
: > 似乎使用率不高, 所以作罷..
:   中山這邊, 目前大約是一天一萬多次 access (http://bbs.nsysu.edu.tw/log/)

     一萬多次看來好像真的很低，因為你一頁 page 恐怕就得傳個幾次，
     比較重要的應該是一天有多少人遷入遷出吧？

     如果一天幾百來位的話，那使用量實在是低的可憐。
     而且如果 talk , chat 等是用 refresh page 那 access page 的次數
     更不準，大概是每次聊天都會有幾千次的 refresh :Q ( 我曾經在 proxy
     看過某個 chat refresh page 達幾萬次。 -_-

maple_future_7.txt

 作者  rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？) 看板  plan
 標題  Re: Maple未來發展
 時間  從零開始 (Mon Aug  3 01:09:21 1998)
 路徑  maple!news.cs.nthu!fromzero
 來源  freebsd.ee.ntu.edu.tw
───────────────────────────────────────

※ 引述《edwardc.bbs@MSIA.pine.ncu.edu.tw (edwardc)》之銘言：
: 【 在 rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？) 的大作中提到: 】
: :     我覺得 client/server 的做法都比 web 好太多了
: :     最近我也在研究 client/server bbs 不過用途不太
:       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: :     一樣就是了。
:         喔? 可以透露一下嗎? :PP

        大概就是類似 bbs 可以串接起來，然後將整個程式完全打散，
        改成命令佇列的方式，也可能用 Thread  來作，好處是寫好後
        整個 client 部份增加修改更為簡單，而且提升大量效率，希
        望能減肥一半。( client 部份是指支援各種 client 的修改，
        改起來會簡單很多，如果有 client 的話 )

maple_future_8.txt

 作者  gc (溫柔的刀)                                        看板  plan
 標題  Re: Maple未來發展
 時間  Mon Aug  3 01:39:07 1998
───────────────────────────────────────

Server Side Scripting and Moudle

使用 Apache 提供的 Moudle 功能是一個很不錯的方法.

我們可以指定一個特定 Moudle 作為 handler 來, 處理所需要的
頁面內容, 就像使用 SSI (.shtml) 一樣, 這是一個很方便有效
的方法. 當然我們也可以撰寫其他的 Moudle 使它能夠處理一般
熟習的 script 語言.

可以提供選擇的像是一般最常用的 shell script, 或是 perl ,
tcl 或是能夠想到的任何一種, 都可以透過這種方式實現. 當然
這也提供了另一個方便的地方讓我們可以輕鬆的處理關於認證的
問題. 因為這樣子我們可以很輕鬆的使用與處理 Cookie.

btw, 如果我們提供的是 JavaScript 或是 VB Script 的 Moudle
可能會被告, 因為前者就是 Netscape 的 Livewire (現在被稱為
Server Side JavaScript) , 後者就是 Microsoft 的 ASP .

cookie 有良好的特性使得使處理這方面的問替變得很容易. 它不
需要塞進 html 當中, 在設定一次 cookie 之後, 每一次對這個
site 的連線當中, 它都會被 browser 傳送回來, 在每一次的資
料傳送當中, 只需要出現一次. 所以我們可以把一個認證的資料
的索引, 放在 Cookie 中, 其於的認證資料都放在 Server 上.
然後根據這個索引, 找出這筆資料, 在加以比對, 以確認這是一
個合法的連線. 我們姑且就叫它 Session Key 好了. :)
(終於發現我寫的都是廢話了嗎 :P )

利用 Cookie 的操作, 我們可以避免一些非常令人尷尬的場面, 例
如被迫使用 GET method 來傳遞 Sission key, 或是認證資料. 可
以發現有些 web-board 系統利用 Java Script 或是 Frame 來隱藏
敏感的 encoded URL, 一個比較聰明的使用者,有可能把JavaScript
關閉或是將 Frame 開啟到另外一個 browser 視窗中而看見這個原
本被隱藏的 encoded URL, 而發現像是這樣的東西:
http://www.foo.net/read_article.html?ID=gc&PASSWD=1234&Board=plan....
不過這也還好, 但是更糟的是, 這個 URL 可以透過 Script 從
browser 的 history 中挖出來. (btw, 一般來說, 不會在cache中)

接下來我們來撿視一下我們最害怕的問題. Process 起起落落的問
題仍在, 雖然 Keep-Alive 可以解決一部份, 不過這會使得這個特
別的 Moudle 耗用相當多的記憶體. 除了因為 Keep-Alive 會使得
"這個" httpd 不會結束之外, 也要考慮到處理 Script 的
Interpreter 也在在裡面. 如果我們考量的真的一個 web-bbs 的話
, 這會是一個致命傷(觀察一下一個 perl interpreter 被載入之後
需要的記憶體容量和它的執行效能). 這在一個工作繁重的 bbs 系
統上是不可接受的.

那麼放棄 Script, 直接以 Moudle 處理呢? 這當然是可以避免掉上
面的問題, 但是這樣會造成我們每次更改頁面的時候, 都被迫要去
更改這個 Moudle , 再者, 用 c 語言輸出 html 是一件令人痛苦的
事情.

那麼, 我們可以採用一個折衷的方法, 一個關鍵字系統, Moudle 只
處理這些關鍵字, 採用替換的方式, 將這些關鍵字替換掉, 這樣的
Moudle 可以很輕薄短小, 而且 load 會很輕. 如果只更改頁面的文
字資料, 只要編輯 html 檔案就可以了.

這個折衷的方法可以兼顧 load 和 customizable. 但是這樣能讓使用
Maple 3 這樣的 bbs 的 adms 滿意嗎? 我想這不大可能, 我們還是沒
辦法避免 process 的起落, 還有原本的 httpd 的問題,如FIN_WAIT_2
等等.

所以, 我們還是必須為 Maple 3 量身定做一個 web-bbs daemon.

--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: news.mis.yzu.edu.tw

maple_future_9.txt

 作者  lasehu (lasehu)                                      看板  plan
 標題  Re: Maple未來發展
 時間  Tue Aug  4 05:23:29 1998
───────────────────────────────────────

※ 引述《rexchen@freebsd.ee.ntu.edu.tw (小旭旭果真小旭旭乎？)》之銘言：
> :   目前缺乏的 talk/chat 部份, 還在努力當中 :)
>     我個人認為會去用 www 界面的反而是對 talk chat 有興趣的人哩 :Q cccc

   其實用 www 界面主要的好處是 browser 到處都有 :)

   對很多使用者來說, 上網路大概只有 browser 或是 xx 網站:)

   talk/chat 不是沒有做, 只少中山web-bbs用 activex 寫過talk componet
   chat 則是用 mschat, 所以 browser 非得用 MSIE. 印像中 yzu 的 ice
   web-bbs 應該是 netscape required :)

   rexchen 對 talk/chat 有甚麼好的做法或是 idea 嗎?


--
Dept. CIE. Natl. Sun Yan-sen Univ.




--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ From: cc.nsysu.edu.tw