GAS xcf 設定檔結構化（Structuring GAS .xcf）

本文解答兩個常見問題：

• 每次修改 .xcf 設定檔，都必須重新啟動 GAS 嗎？
• 同一個 GAS 設定項目，是否需要在每個個別的 .xcf 檔案中重複定義？

GAS 設定與 Web 應用程式設定的分離

正確的做法是將兩類設定清楚分開：GAS 本身的設定應放在主設定檔中，而個別 Web 應用程式與 Web 服務應用程式的設定則應各自放在獨立的設定檔裡，不要混入主設定。

這樣的結構帶來一個重要好處：修改個別應用程式的設定時，無需重新啟動 GAS dispatcher。主設定檔中 APPLICATION_LIST 與 SERVICE_LIST 內的 GROUP 元素，會引導 GAS dispatcher 去尋找這些個別的設定檔。

抽象父應用程式模式

個別應用程式的設定檔中，只需定義該應用程式特有的值，其餘設定則繼承自一個抽象父應用程式。以 Calculator.xcf 為例，只需指定 PATH、MODULE 與 ACCESS_CONTROL，其他所有設定都從以下抽象應用程式繼承：

<APPLICATION Id="ws.default" Abstract="TRUE">

這種繼承模式能有效避免在多個設定檔中重複相同的設定，大幅降低維護成本與設定不一致的風險。

多 dispatcher 實例的資源覆寫策略

若同一台伺服器上需要執行多個 dispatcher 實例，可以使用 -E 命令列參數，在執行時期覆寫特定資源值，而無需為每個實例各自維護一份設定檔。

例如，以下範例示範如何用相同的設定檔啟動兩個 httpdispatch 實例，但分別透過 -E 旗標指定不同的 port 與路徑：

httpdispatch -f gas.xcf -E RES_NAME_PORT=8090 -E RES_NAME_PATH=/app1
httpdispatch -f gas.xcf -E RES_NAME_PORT=8091 -E RES_NAME_PATH=/app2

設計原則

本文的核心觀念是：設定應遵循「定義一次，多處參照」的原則。透過抽象父應用程式繼承通用設定、透過 GROUP 元素引用個別設定檔、透過 -E 參數覆寫執行時期資源，可以大幅減少重複設定，降低日後維護的負擔，也避免因設定不一致而產生的問題。