eFML 白皮書

 第一章：前言

近年來基於 HTTP/HTML/XML 的 Web 架構挾其跨平台、零客戶端安裝、 集中式管理等優勢，業已成為分散式服務的首選，但也由於Web的發展遠遠超出原先「交換文件」的設計，Web 架構的不足隨著應用的拓展逐漸突顯出來，本白皮書將細述現行 Web 架構的不足與缺失，並提出易符的解決方案：以 FML 為基礎的新一代網路服務架構。

第二章：Web 架構的基本問題

 第一節：分散式服務的發展歷程

第一代：大型主機架構 Mainframe + Terminal

第二代：主從架構 Client Server

第三代：Web 架構 Web Server+Browser

從上表不難看出 web 架構取得主流地位的原因：極低的客戶端建置、維護和學習成本，當客戶端的數量超過某個數量時，Web 是唯一能適配的方案。

要了解 Web 架構的缺失，必須從 HTTP 和 HTML 格式說起，首先談談 HTTP ( Hyper Text Transfer Protocol )，HTTP和其他以TCP/IP為基礎的通訊協定，有一個顯著的差異，即不保留永續連線，資料一旦傳遞完畢，連線即中止。(註一)從而有效地減輕伺服端管理連線的負擔，並使伺服器同時服務的對象大幅增加。這種設計對「超文件」來說很理想，數秒鐘由網路下傳的資料，人類也許要好幾個小時才能消化完畢，在這期間，保持永續連線的確是沒有必要的。因此，相對靜態的應用可選擇HTTP，互動性要求越高的場合，則越不適用。

其次，HTML ( Hyper Text Markup Language) 是一個基於 SGML 的文件標誌規格，HTML 相對SGML來說，不但嚴謹性可議，考慮也欠周詳，最大的缺點是文件結構和視覺呈現混淆不清(註二)，使得HTML 基本上只能給「人」看，電腦很難做進一步的處理。

但由於 HTML 夠簡單，加上瀏覽器和製作工具的不斷的改進，HTML 終於能取代其他方案，成為市場主流。

第二節：Web 的發展歷程：

Browser 端的發展--視覺呈現方面：

1.   純 HTML：基本的文字、大小字型、顏色設定、超聯結

2.   表單：提供基礎的互動功能

3.   TABLE：呈現更豐富的內容

4.   FRAME：減少 與 server 之間的通訊量

5.   DHTML/CSS：Document Model 非 Application Model

l   CSS提供精準版面定位，較好地利用客戶端的字形資源

l   主要問題-各品牌及版本 browser 之間的不一致性，

l   製作人員必需費很大力氣才能保證客戶端呈現出理想的效果。

6.   多媒體擴充：Macromedia Flash(註三、四)

l   Flash 的巨大成功證明了：使用者對聲光效果和互動性的需求，遠超學者們的想像，Flash 充份利用客戶端的圖形能力，搭配功能強大的製作軟體，讓非IT 背景的人員能夠發揮創意，製作高度互動，多采多姿的動畫和遊戲。有些網站乾脆以完全以Flash 來建構。

邏輯方面：

l  Browser Plug-ins：Plug-ins 是各家瀏覽器允許的擴充機制，直接以目的碼形式運行，因此不但不能跨平台，甚至也不能跨Browser 。

l    Java Applet：JAVA 最初就是為了要解決分散式運算一項重要的需求：
程序編寫一次，處處可行。Java 以byte code 型式分配到客戶端，必需依賴虛擬機器方可運行，Microsoft 抓住這個致命的弱點，故意將 JVM 寫得很爛，激起使用者的反感、降低其使用意願，並偷偷「污染」規格，讓 JAVA 「處處可行」的承諾無法兌現。(註五)

l    Scripting：相較起JAVA在Windows 平台上的吃鱉，遠親JavaScript就風光得多(註六)，Microsoft 試圖用 VBScript來取代 JavaScript，意外地沒有成功(註七)。    事實上 JavaScript在此扮演著一個重要的角色：文件物件模型(DOM)的控制語言。舉凡事件處理、表單核查、各類視覺(DHTML/SVG)元素的控制，都非用Javascript不可。有了Javascript，更多的邏輯可以移到客戶端運行，從而降低頻寬的需求和系統的複雜度。

客戶端技術的主要困境：

1)圖形能力的嚴重不足

HTML 的圖形能力極為有限，圖形必需在伺服端轉成圖片傳輸到客戶端顯示。也就是說，如果想呈現特殊的字形變化，甘特圖，統計圖表等等，都必需以圖檔形式傳遞，頻寬消耗很大。Flash 可以克服這個問題，但由於Flash 以Plug-in 形式存在，是一個獨立的顯示區域，終究無法和HTML網頁圖文做充份的整合。

2)Microsoft 的獨霸

目前在 PC 上「一線」的產品，只剩下 IE , Netscape和 Opera，其中 IE 的佔有率超過 90% (註八)，和 Windows 作業系統的佔有率很接近。 Netscape, Konquerer 主要以 Linux 使用者為主。Microsoft 挾作業系統、編製工具(FrontPage)和使用者基數，三位一體的優勢，已經可以為所欲為，全面地主導瀏覽器的發展方向，短期內是不可能出現能與之抗衡的瀏覽器，大局已定，在架構不變的前提下，任何的挑戰都是徒勞的。

3)複雜度

隨著HTML功能越來越多，複雜度已經到了難以控制的程度，而且由於能夠上網的設備日益多樣化，HTML 的複雜度已嚴重影響到系統開發的成本和效率。因此才有WML等減重的嘗試。

伺服端的發展：

原本Web伺服器只能提供靜態網頁，所謂的「靜態」，指網頁在伺服端和客戶端的內容一致，網頁內容必須事先編寫完成。但真正有用的是「動態網頁」：根據客戶的需求，即時產生的網頁。搜尋引擎、討論區、訂購服務、競標等等應用，必需是動態生成的網頁。(註九)

(1)  CGI：這是最早實現動態網頁的技術，幾乎所有的Web伺服器都支持這個方案，

(2)  缺點是：對每次的客戶端需求，必需執行一次程式，造成潛在的問題。(註十)

(3)  Server Extension:針對 CGI 的效率問題，某些伺服器會將內部的函式和資料結構開放出來，讓人們可以進行擴充。缺點是程式很難移植到其他的伺服器。

(4)  Server Side Scripting：CGI 和 Server Extension 皆是以傳統程序為中心的思考，程式碼為主，HTML標誌以字串型式輸出，這種型式的程式很容易造成維護的困難。PHP 擴充了 Server-Side-Include的(註十一)觀念。提出了以 HTML 為中心，嵌入程式碼的做法，由伺服器端執行這些程式碼(存取資料庫之類)，轉換成純HTML文件送到客戶端，這個架構大幅降低了 web 程序開發的困難度，更棒的是，美工人員也可以參與系統的開發，(HTML 編製工具只要將嵌入的程式碼當作註解略過即可)有了Server Side Scripting ，動態網頁變得多采多姿起來。除了PHP，還有 ASP (以 VB 為語言)、JSP之類，皆為相同的架構。

(5)  Servlet, J2EE：由於 Server Side Scripting 門檻很低，漫不經心的程序員很容易寫出缺乏整體規劃，邏輯操作雜亂地散佈在一堆網頁之中，又造成了維護的困難。Java 提出 Servlet 和 J2EE 架構，讓程式員可以將重覆使用，安全和效率要求較高的程式碼預先編成二元程式。

伺服端技術的主要困境：

(1)  無法準確掌握客戶端的事件：每次互動必需發出 HTTP 請求。

(2)  無法得知客戶端實際呈現效果。

(3)  沒有單一的解決方案：由於每種技術各有優缺點，各自解決部份問題，因此在一個實際運行的系統中，往往要混合使用 好幾種技術。比方說，後端資料庫存取用SQL，企業邏輯使用 PHP，前端表單驗證用 JavaScript ，畫面的控制用 CSS，語法各異，並有各自的設定和調校方式，這造成系統整體複雜度大增，開發及維護成本大幅增加。

第三節：系統造成的障礙

為了要保證在各個系統中皆能呈現HTML ，因此在設計之初，只能採取最基本的功能，以表單 (FORM ) 為例，HTML 僅支援最簡單的按鈕，下拉選單，文字輸入盒等，進階的視覺元件如樹狀結構、滑桿 (Slider) 、複合盒 (ComboxBox)還有自訂的元件 (custom controls or widgets) 都沒有相應的HTML 標誌。簡言之，HTML為了普及度的緣故只能取各系統的交集。如果採用越多「特殊功能」，越難保證在客戶端的呈現效果，由於這個限制，Web 架構無法實現高級的圖形介面系統。

另外，由於 Web 是架構在現行的圖形作業環境上，作業系統的不足也一併繼承，除了英文，其他語言必需依賴底層系統的字形，否則無法正確顯示，這無疑是宣判其他語言在網際網路世界的次等地位。對漢字來說此問題更顯突出，新浪網的成功充份說明了這點。(註十二)

第三章：新的描述語言 eFML

綜上所述，現行 Web 架構的缺失，不但造成了成本的增加，更嚴重地妨礙到中文資訊的傳播，我們覺得 Web 有必要進行一次從根做起的重新規劃，去蕪存菁，找出一條可行的路來。

Forth 有幾項特點，非常適合作為網際網路所有子系統之間溝通的母語。

  1)Forth 非常精簡易學，並有非常好的彈性。

  2)Forth 的執行效率非常高。

  3)Forth 也同時是一個 interpreter，處理結構化文件最為直接有效。

  4)Forth 是一個虛擬機器，在任何硬體上都很容易實作出來。

  5)Forth 很容易以硬體線路實現，這對嵌入式設備來說意義重大。

簡而言之，Forth 兼具編譯語言的效率嚴謹和直譯語言的彈性易學，如果說 XML 是描述資料的超語言，那 Forth 可說是同時能描述邏輯和資料的超語言。在下面的內容，我們將展現這個獨特的路數 (approach)所帶來的驚人效益。

我們首先提出了一個eFML的構想，一舉解決伺服端及客戶端所有邏輯和資料的描述需求，eFML 和傳統 Forth 源碼的唯一差別是：註解和指令的位置互換，

傳統Forth 源碼：指令是預設態，註解文字是特殊態 ( ) 內或 \ 之後的文字

eFML          ：文字是預設態，指令是特殊態。 < > 內是指令

eFML 檔案內容看起來就像這樣：

<Forth 指令>...文字...<Forth 指令>...文字...

eFML 和 XML/HTML 有幾個顯著的不同：

1) HTML 每個標記只能有一個功能，和若干個參數。

    比方說，如果要呈現「有底線」的「大字」，必需用二個標記：<FONT SIZE=7><U>

    eFML 可以這樣寫：

    <7 SetFontSize><underline>  或   <7 SetFontSize underline>

    這樣指令和參數可以結合起來，減少大量的 < > 。

2)  eFML 可以立即定義新的標誌(指令)

    <: F7U 7 SetFontSize underline ;>

    此後， F7U 就是一個新的標誌：  <F7U>這是有底線大字

    這個方式可以讓網頁大幅簡化，清晰易讀。要創造中文標誌，也是輕而易舉。

eFML 能夠：

(1)  取代 HTTP，成為機器與機器之間的控制及資料傳輸協定。

(2)  取代 HTML，成為頁面的排版語言。

(3)  取代 XML ，成為結構化資料的描述語言。

(4)  取代 Java Applet，可製作跨平台的視覺元件。

(5)  取代 Javascript ，成為互動事件和文件結構的控制語言。

(6)  取代部份Flash 的功能，可允份利用客戶端的圖形資源，字形、圖形和報表皆可以直接用指令的方式於客戶端產生。

(7)  取代 PHP, Serverlet, CGI 等所有伺服端技術，直接操控伺服端所有軟硬體資源。

(8)  取代所有的遠端傳呼協定，如 RPC、DCOM、COBRA，以一致的語法和介面，傳遞跨平台邏輯。

(9)  加上了基本硬體和繪圖能力，甚至可取代現行的作業系統，做為嵌入式設備的標準圖形環境(GUI)。在這個環境下，所有的應用程式都是以 eFML Browser 為展現平台。

傳統的作業系統，將應用程式當作系統穩定性的大敵，重重的保護，來限制應用程式的活動範圍，其代價即是複雜度的增加和效率的損失。從 Forth 的觀點，應用程式即作業系統的延伸，兩者是沒有差別的。

同樣地，傳統的瀏覽器，將HTML 當作資料來處理，HTML 加入新的標誌語法，瀏覽器就必需內建更多的處理程序來應付之，這直接導至瀏覽器日益龐大和複雜化，而這些先進的功能，往往不被充份使用，使用者卻必需揹負額外的開銷。

從 eFML 的觀點，超文件即是瀏覽器的延伸，瀏覽器既有的功能，直接調用之，瀏覽器不足或不適之處，eFML 定義出新的操作方式，被編譯後隨即和瀏覽器融為一體。因此瀏覽器可以變得非常精巧，而又可以處理所有新的需求。

準此，

(1)  eFML 解決了版本升級問題，因為每一份超文件，都能引導瀏覽器「學習」新的能力。

(2)  Web 由原先的主從架構，蛻變為平權式分散架構，伺服端和客戶端的角色變得模糊，換句話說，要求服務時，是客戶端，提供服務時，則為伺服端，這雙重角色，可由同一個Forth系統扮演。

(3)  由於eFML語言的單純化，省去各種語法之間的介面轉換和彼此牽制，整體系統因此變得非常簡潔高效，並且允許開發者徹底拋開作業系統的限制，完全從應用本身的角度出發，量身訂作出最適當、最精簡的系統。

FML 在 Pocket PC 上的運行畫面。

eFML 在 PC 上的運行畫面。

註一：HTTP 1.1 版做了一個補強，即允許設置 keep-alive 參數，節省批次下載檔案時，摧毀/重建連線的時間。最明顯的效益是：當網頁嵌有很多小圖片時，Keep-alive 可以有效提升頻寬的使用率，縱然如此，HTTP 本質上還是一個不維護客戶端狀態的通訊協定。

註二：針對HTML文件結構和呈現不分的缺點，XML 允許自訂義新的標誌來準確地描述文件的結構，俾使在不修改程式的前提下，能夠處理任何符合 XML規格的文件。這是一個觀念上重大的突破，可惜正是由於抽象性，必需輔以 XSLT 、DTD等規格，才能達到 HTML 的效果。      對一般人來說，門檻反而更高了，因此XML的立意雖好，時至今日，XML或許已在後端的資料描述和交換取得不少成就，但終端用戶方面，依舊是由HTML 主宰的局面。

註三：RealPlayer 也是重要的多媒體擴充，但一來它不是基於HTTP 協定，二來 Microsoft Media Player 已逐漸取代 RealPlayer 的地位，成為最多人使用的串流影音標準。所以此處略過不提。

註四：有鑑於Flash為Macromedia專屬格式，Adobe 對Flash 的成就也頗為眼紅，W3C 遂推出了基於XML、完全開放的 SVG 規格，試圖挑戰 Flash 的地位，但Macromedia 畢竟是行家，憑藉冼練的圖形能力，較高的執行效率，和完善親切的製作工具，穩據生態位的Flash，除非犯了嚴重的錯誤，讓對手有可乘之機，否則要取而代之還是遙遙無期。

註五：JAVA 既已惡名昭彰，Microsoft就不必再玩這種小把戲了， 堂堂推出 .NET 架構和C# 語言，擺明要做掉 JAVA。戲正上演，劇情起伏難料，這裡就不多說了。

註六：嚴格說來，JavaScript 和 Java 差異很大，除了語法上有些雷同之外，骨子裡是完全不同的兩種語言。

註七：在Pocket Pc 上面，Microsoft 乾脆拿掉了對 VBScript 的支持。

註八：Netscape 在 1995 年也曾達到這個水準，Microsoft 痛定思痛，急起直追，不到三年，就取代了 Netscape 的地位。

註九：動態和靜態係根據英文的 dynamic 和 static 而來，這個翻譯並不好，要向一般人說明 Flash 是「靜態」內容頗費唇舌 (明明在動，為何是「靜態」？)，比較好的譯名是：「預製」網頁和「現製」或「即時」網頁。

註十：在 Windows 系統上，創造行程(Create Process)的代價很高，Unix 好一些。但只要在有虛擬空間設計的作業系統上，都要付出相當的時間和記憶體空間之代價。

註十一：SSI ( Server-side-include )，伺服端進行字串替代後，再送到客戶端。比方說： $TIME 會取代為目前時間。

註十二：新浪網把中文字全部轉成圖片來顯示，從而保證任何平台皆能正確顯示，付出的代價是無法檢索及再利用，還有十倍以上頻寬的浪費。(每個中文內碼只要2 Bytes，而轉成圖片16x16 點陣就要 32 bytes )

上一頁