在講 annotation processor 的實作之前，我們要先了解一般的處理方式，通常是寫 XML parser 去處理這些 RSS 的 tag ，這跟我們的 processor 實作息息相關，因為 annotation processor 產生出來的程式碼其實就是我們一般的 XML parser 的程式碼。 一般來說，處理 RSS tag 可以直接用 XML 的 parser ，因為他跟 XML 的結構和格式相同，這篇主要會講解如果使用純 kotlin 的方式寫 XML parser ，會有哪些選擇，也會分析哪個 parser 比較符合我們的需求。

在 XML parser 中，我們可以把 XML 檔案內容看成是一顆樹，每個節點就是一個 tag ，而節點底下也會有他的子節點，也就是它底下包含的 tag 。

<channel>
    <title>the title</title>
    <author>the author</author>
    <description>description</description>
</channel>

以上面的 XML 為例，我們有一個 channel 的根節點，底下包含了 title 、author 和 description 三個子節點，有些 parser 是用 steam 資料流的方式載入資料，所以他們的特性就是按節點的先後順序去取資料。

下面列出三個的 XML Parser，我們分別來分析一下他們：

• DOM
  • 把整個 XML 結構載到記憶體裡，然後爬裡面的資料，所以當檔案很大的時候，會耗費比較多的記憶體。
  • 不是以 steam 資料流的方式載入資料，所以方便跨層尋找 tag ，不依賴節點走訪的先後順序取資料。
  • 可以對資料進行插入和刪除 tag 。
• SAX
  • 內部實作是 event pushing 機制。
  • 以 steam 資料流方式載入資料，讀到哪，寫到哪，依賴節點走訪的先後順序。
  • 比 DOM parser 省記憶體。
  • 在 runtime 時，效率比較好。
  • 不可以對資料進行插入和刪除 tag 。
• StAX
  • SAX 的兄弟版本，差別只是內部實作是 event pulling 機制。
  • 以 steam 資料流方式載入資料，讀到哪，寫到哪，依賴節點走訪的先後順序。
  • 比 DOM parser 省記憶體。
  • 在 runtime 時，效率也比 DOM parser 好。
  • 也無法對資料進行插入和刪除 tag 。

以我們要做 RSS parser 的需求來說，我們會需要方便去跨層尋找 tag ，而且有些時候 tag 內可能會夾帶一些 HTML 的 snippet ，如果要透過 SAX 或是 StAX ，勢必是要寫很多特例處理，不然就是要限制 RSS source 不能夾帶 HTML ，但這樣會降低 library 的使用彈性。雖然說 DOM parser 用比較多記憶體，但他可以為我們的實作帶來一些方便，也滿足我們跨層尋找 tag 的需求。另外，RSS 的單檔也不會太大，所以記憶體的耗費不會是太大的問題。總結以上的觀點，我認為使用 DOM parser 來作為基底 parser 是比較理想的選擇。

附註：
1. Event Pushing: 使用者要跟 API 註冊類似 callback 的東西去獲取 event，所以使用者對於 event 的控制度較低。
2. Event Pulling: 使用者可以透過 API 主動去要 event ，要 event 的當下就 generate 那個 event ，所以使用者可以控制甚麼時候產生 event 。