[QOTD]最近想了多事情，往往寫到一半就換題目，所
以往往會有寫到一點就換一篇寫的現像，但事
實上也知道有些再繼續寫下去的機會已經相當
不高了，所以乾脆把一些做個了結吧。
*1
在 phpNuke 中，最重要的有幾個常用的系統包
含新聞、論壇、下載、連結、會員等幾個重要功能，
其他大多是其延伸，而目前的 backend.php 主要是
針對新聞去抓資料成 RSS 後餵給別人，而別人在將
此 RSS 解成 block 放在自己的網站上面。
但並沒有把別人的資料與自己的資料同步的功能
，因此就很困難的相互為用，所以如何寫出一個能夠
互相交換資料的 Funtion 是很重要的。
但除此之外，有幾個重要的前提，包含完全希望
在增加 Block 後去完成，不要再增加系統管理者的
負擔，也就是說使用者只要透過讀取網頁，就可以觸
發同步機制，且被同步的對像也是透過網頁的存取去
完成，除此之外，更是希望所有的功能都是透過資料
庫去完成。
因為是網頁的讀取，所以只有在主動端發出一個
須求後，被動端也只有一個反應，而是否要透過一連
串的觸發去完成，這可以考慮，但也並不是不可能。
一次完成的風險是在網路不好時，所發生的資料
不完整時造成解析錯誤，或者是時間拖太久造成連線
中斷，而若是透過雙方一連串的觸發，雖然可以避免
上述的問題盡量不發生，但要解決的是在 Race
Condition 所造成的前後不一致的現像，但這些都還
好。
基本上，任何一端，只要經過 Authorization(
授權 ) ，然後給所要同步的功能，時間，指標，另
一端可以就其所給的資訊回傳資料讓之寫入，而任何
一方也要自己做連線控制，而不至於雙發無限制的發
出同步請求後造成系統負荷過高的問題。
*2
雖然用一次一篇會簡化流程，但效率是有問題的
，因為牽涉到會 Lock 的的情況下，不太可能一次只
傳一份資料。
把這系統當成個 Agent，這個 Agent A 會傳給
另一個 Agent B 說他已經從 B 身上獲得甚麼資料後
，B 然後判斷出來跟 A 講新的資料，然後 A 經過判
斷後儲存，看須不須要再去問一次。
用三個東西來做控制，總篇數是最單純的，但這
會變，時間這是最安全的，另一個就是很單純的
Message-ID，而這 Message-ID 甚至可以簡化到以站
台、使用者與時間來做 Key，因為同一個使用者要在
同一個時間發多篇文章是不正常的。
*3
[參考]
1. RDF
2. RSS
3. OWL
4. syncML
5. XML-RPC
6. nntp
7. NewsML
[基本要求]
1. 要完全使用HTTP的方式去傳遞
2. 可以輕易的用Plug-In的方式去架設
3. 不用改變既有的資料庫格式
4. 不一定要用crontab去維護
5. 可以透過別人(第三者)傳遞
6. 不介意開新的資料庫，但不用檔案系統
7. 可以做基本的權限與認證
8. 不要用模擬的方式去傳遞
9. 可以依網路狀況去做設定大小與頻率
10. 自己有Lock的機制
*4
**********************************************
*1
12/20/02 7:20 pm，到民權西路站，準備回淡水
，這星期六日打算做甚麼呢?
*2
因此，流程會如下。
1. 當某人讀取資料時，會呼叫自己端的同步程式。
2. 查表找出要發出同步的 Server，並確認上次開始
同步時間是否在間隔內，若是在間隔外的話，修
改開始同步時間，並將發起緒設為 1，開始同步
。
3. 若是在間隔內的話，確認同步完成指標是否為正
確，確認發起緒是否小於一定值。
12/24/02 9:18 am，在捷運日記寫流程是件很奇
怪的事，且我後來發現這流程有很大的問題，包括須
要控制 Race Condition，所以最好不要
Multiprocessing，因此須要 Locking 之類的。
現在在忠孝敦化要準備上班了，雖然今天是
12/24，但或許是沒有假期的關係，所以氣氛很淡吧
。
*3
12/24/02 7:31 pm，現在到復興崗站了，應該有
可能在 8:00 前回家說，今天是難得的 Xmas Eve，
就早點回家吧。
*4
12/25/02 8:15 pm，先寫到這邊，先切第一篇好
了，已經到奇岩站了。很幸運的在火車站有座位做，
所以才能這樣。
文章定位：
