RFC-0104：相對元件網址

摘要

這項提案旨在將相對元件網址新增至元件架構。相對網址遵循 網址 RFC 3986 規格。初始相對網址實作功能僅支援片段，不支援含有主機或套件的相對網址。相對網址會相對於元件最接近的祖系，並包含絕對網址。相對網址解析器會在執行階段解析相對網址，藉由尋找具有絕對網址的元件最接近的祖系，判斷正確的主機和套件。

提振精神

缺少相對網址會影響元件的重用性。元件應可在新的套件中加入及使用，而無須修改。不過，如果元件使用絕對網址宣告子項，則這些子項一律必須從絕對套件中解析。如果父項網址在其他套件中重複使用，可能會導致問題，因為父項和子項現在位於不同的套件中。相對網址表示「我希望這個元件一律從相同套件中解析」，可促進密封性和重複使用。

在需要密封性，以及元件經常在新的測試套件中重複使用的測試中，使用相對網址特別有用。

另一個好處是相對網址很方便。元件作者不必重複多次輸入套件名稱，而且錯字造成的錯誤機率也較低。

範例：Isolated-Driver-Manager

我們來看看具體用途。驅動程式架構團隊希望使用相對網址，以便更輕鬆地編寫隔離的驅動程式庫整合測試。

以下是這類測試的示意圖：

整合測試需要驅動程式架構與多個測試元件共同運作。所有這些元件都應從測試套件中載入，以便一併更新，並可存取位於測試套件中的測試驅動程式。

如果沒有相對網址，就必須針對每個新測試編輯 isolated-driver-manager.cm，讓其指向該測試套件的本機 driver-manager.cm 和 driver-index.cm。例如，它會指向：

• fuchsia-pkg://fuchsia.com/my-test-package#meta/driver-manager.cm
• fuchsia-pkg://fuchsia.com/my-test-package#meta/driver-index.cm

使用相對網址時，您不必為每次新測試編輯 isolated-driver-manager.cm，只需使用相對網址語法即可，例如：

• #meta/driver-manager.cm
• #meta/driver-index.cm

值得一提的是，目前 CFv2 IsolatedDevmgr 會在建構期間產生頂層領域，以便插入正確的套件名稱。

設計

相對網址的格式

相對網址應遵循 URL RFC 3986 中所述的格式。相對網址會重新建立至具有絕對網址的最近祖系。

在初始實作階段，相對網址只支援片段。系統一開始不會支援宣告查詢參數、路徑或主機名稱的相對網址。但這些裝置可能會在日後支援。

舉例來說：

相對網址：

#meta/child.cm

含有絕對網址的最近上層：

fuchsia-pkg://fuchsia.com/my-package/0/?hash=1234#meta/parent.cm

已解析的網址：

fuchsia-pkg://fuchsia.com/my-package/0/?hash=1234#meta/child.cm

相對解析器

RelativeResolver 將成為相對網址的解析器。解析器目前是針對特定網址配置宣告；RelativeResolver 將成為空白配置的解析器。RelativeResolver 會在 component_manager 中實作。當 RelativeResolver 解析元件時，會向上瀏覽該元件的祖系，找出第一個元件網址非相對的祖系。解析器會將相對網址重新對應至絕對網址。方法是複製絕對網址，然後將片段部分替換為相對網址的片段。接著，RelativeResolver 會針對重新指定的網址提出解析要求，並正常處理。

這是一個例子，說明如何逐一查看多個相對元件，找出絕對網址。

以下是 RelativeResolver 解決 #meta/child.cm 的步驟：

1. 逐一檢查祖系，直到找到第一個絕對網址

• 第一個絕對網址為 fuchsia-pkg://fuchsia.com/my-package#meta/realm.cm

1. 將相對網址重新命名為絕對網址，藉此建立絕對網址。

• 我們的絕對網址為 fuchsia-pkg://fuchsia.com/my-package#meta/child.cm

1. 傳送絕對網址的解析要求

• 在這種情況下，我們的要求會由 fuchsia-pkg 解析器正常處理

1. 傳回解決要求的結果

實作

我們打算將 RelativeResolver 實作為元件管理員提供的內建解析器。RelativeResolver 會新增至根元件的環境，以便由從該環境延伸的任何元件使用。

成效

這對效能影響應該不大。RelativeResolver 是在元件架構中內部實作，可執行祖系搜尋和完整網址解析，且無需進行任何 IPC 呼叫。

安全性考量

這對安全性應該不會造成太大影響。您必須特別小心，確保系統能正確剖析及重新設定相對網址。

隱私權注意事項

這不會影響隱私權。

測試

相對解析器會進行單元測試，並新增使用相對網址的整合測試。

說明文件

我們會在元件架構網址說明文件中新增其他說明文件。

缺點、替代方案和未知事項

替代做法：在建構期間解析相對網址的 CML 範本

另一種達成相對網址的方式，是使用範本 CML 檔案，讓系統在建構時解析相對網址，並將絕對網址放入編譯的 CM 檔案中。

這麼做有幾個優點：

• 不需要變更架構執行階段。執行階段只會處理絕對網址。
• 相對網址會在建構期間解析，因此在執行階段不會解析任何內容，這可讓建構後分析作業更輕鬆。

這麼做也有幾個缺點：

• 一般來說，CML 不希望使用範本。
• 在建構系統和 cmc 之間增加更多整合功能。
• 由於樹狀結構外元件可使用不同的建構系統進行建構，因此建構系統整合作業會變得更複雜。
• 如果套件包含預先建構的元件，這項功能的運作方式不太清楚。

替代方案：從 /pkg 讀取的相對解析器元件

另一種達成相對網址的方式，是使用相對解析器元件，從 /pkg 讀取並解析網址。

優點：

• 解析器功能並未在元件架構中實作，因此更具模組化

缺點：

• 每個需要相對解析器的元件都必須在套件中加入相對解析器元件，並在 CML 檔案中正確連接
• 這與未來元件架構安全性措施相牴觸，因為元件將無法完全存取 /pkg，只能存取其元件檔案。

替代做法：相對網址採用「relative://」架構

我們可以為相對網址建立特定配置。這樣一來，由於所有支援的網址都會是「有效」的完整網址，因此剖析網址會變得稍微容易一些。

優點：

• 更輕鬆的網址剖析

缺點：

• 不符合網址規格

既有技術與參考資料

網址規格定義了 網址 RFC 3986 中的相對網址。在替代方案一節中，我們會考慮使用這個確切規格。