第二章 目標

2.1 API 的目標

Image I/O API 的設計是受到了對支持一系列主要目標的渴望的影響。每個目標都提供了對應的一系列API功能被設計的理由。這些目標可被分為主要由客戶端應用程序需求所推動的和被服務器端應用需求推動的。當然，這些主要目標僅代表了API所有能力的一小部分。它們在此列舉的目的是提供API設計動機的一種概念。
作為概覽的通用規則，不論何時，在方便應用開發者使用及插件開發者使用之間的權衡都是必須的，應用的開發者被賦予了更高的優先權。由于相對來說希望編寫插件的API使用者還是占少數，而且甚至這些編寫插件的開發者通常也不會寫為了支持相關的圖片格式使之立即投入使用的代碼之外的東西，所以把復雜的東西盡量推到插件開發方而不是應用程序開發方是很有道理的。

為了減輕插件開發的復雜度，我們提供了一些用來作為公用函數的工具方法和實現類。然而，將所有功能情景都涉及到是不可能的，并且如果提供的工具類和方法過量的話，所有API用戶的機器付出的額外開銷就會變得很大，即便這些用戶可能并不需要用到這些標準包之外的功能。當在使用多個、獨立開發的插件時，可能也會造成一定的贅余，但大多數用戶還是傾向于在任何情況下都盡可能減少使用插件的數量。所以我們認為，加載理論上可能會被分享但實際上沒有的代碼，其性能的開銷更容易超過在使用插件時，由于加載一些重復代碼而造成的的開銷。

2.1.1 客戶端應用程序的目標

可插性
使用了Image I/O API 的應用程序應該具有無需任何重寫和重編譯既可自動使用新插件的能力。這就需要插件盡可能地遵守一系列格式中立的接口。然而，每種圖像格式都有自己獨有的且插件必須要可以暴露給應用程序的屬性和功能。這將由允許插件擴展一系列API 的接口來實現。應用程序在不知道具體使用了哪個插件擴展之前，將繼續以通常插件的情形去使用這些功能，而那些確定自己使用了具體插件的應用程序則可以使用被擴展的接口。
針對不同圖像格式，不論是通常的還是插件專用的，對元數據（圖片格式中除了圖像數據以外的信息）獲取，都由插件提供的元數據訪問方法來實現。包括工業標準格式，由API定義的插件中立格式，以及插件專用格式。

插件的自動或手動選擇及安裝
對于通常無需用戶干涉圖片加載過程的簡單應用程序來說，基于文件的內容自動選擇對應的讀取插件就很重要。然而，要令人滿意，那么在用戶不需要的時候，就得避免加載和實例化那些復雜的插件。插件必須能判定它是否可以在不必加載自己所有代碼的時候就處理一張給定的圖片。為了實現這個目標，插件們將由一種不加載插件主體代碼就可以進行簡單判定的服務提供者接口機制實例化。
所有同某個插件相關的二進制碼（.class）文件應該被放在一個JAR包里，這樣它就可以被永久性安裝到Java運行時環境里，或者使用應用的CLASSPATH機制被動態的載入。

手動插件選擇
盡管自動插件選擇對很多應用陳旭來說很方便，但對于許多更加專業的程序來說，對插件選擇處理做更高級的控制也是必須要有的。該功能由應用程序自行判定和操作插件的運行時注冊機制實現。

直接I/O、基于磁盤及網絡
漸漸地，應用程序需要同時處理基于磁盤的和基于網絡的數據。在很多時候，甚至基于磁盤的數據都會因為其他API的需要而通過某種InputSteam被處理。Image I/O API 提供了一系列允許處理來自File、InputSteam或其他來源的數據的接口，從而保持前向后向查找的方式統一。API允許新的I/O接口，包括對圖片獲取及輸出設備的直接接口直接使用而不需要重寫程序代碼。

訪問元數據
在圖片數據旁邊的元數據有時和圖片數據本身一樣重要。Java Image I/O API 提供了對元數據靈活且徹底的訪問。由于元數據可能會采用不同形式、并且包含專用的信息，所以提供對元數據直接訪問的通用API是十分困難的。因此，API需要插件將它們的元數據轉換為XML文檔結構，也許會附加對對象的引用作為紋理數據的補充。一旦這些工作完成了，元數據就可以使用標準的XML DOM（文檔對象模型）接口來進行訪問和修改了。插件與插件之間文檔的語法可能是不同的，但其結構卻可以在對插件沒有任何了解的情況下被展示、修改或遍歷。

對高級應用程序的支持
為了支持高級應用程序，API必須支持訪問諸如“縮略圖”、單文件里儲存的多張圖片、多分辨率圖像及瓦片拼接圖形等功能。必須具有解碼某張巨大圖片中的某一部分的功能和在解碼時進行二次抽樣的功能，從而支持對極巨大圖片的展示。當寫入圖片的時候，必須要保證不需要現將整張圖片存入內存，而是按塊切分，逐塊寫入圖片。

2.1.2 服務器端使用的情況

動態圖片生成
現代Web服務器通常動態地生成大部分內容。Java Servlet 和 Java Server Pages（JSP）的API提供了方便的根據來自網絡瀏覽器請求，生成HTML頁面響應的途徑。給每個用戶生成的自定義HTML可能都是不同的，針對圖片內容的定制也是可以的。
在很多時候，需要動態的生成圖片內容。例如，對股市價格圖表的支持。盡管為每個列出的股票產生并保存有限數量個圖表文件也是可行的，但如果允許用戶進行自定義操作，比如價格所處的時間間隔需要顯示出來或者需要對一個或多個股票之間進行價格的比較時，需要保存的圖片個數將會變得無法預測。只用使用動態生成的途徑才可能支持這種定制化。

圖片定制化
網絡圖片通常是“一個大小適配所有”的，不管接受者的顯示能力直接傳送相同的圖片數據。而激增的無線或手持設備需要定制化的適合他們有限顯示寬度和顯示能力的圖片。桌面電腦頻繁增加的顯示分辨率，也會導致一些網絡圖片顯得過小。缺乏可放縮圖片的同樣會給視力障礙的用戶造成麻煩。服務器端圖像定制化可基于用戶偏好的分辨率、色彩特征為所有用戶提供最佳化的圖片，

2.2 非目標

線程安全
一個指定的ImageReader或ImageWriter實例不需要支持對其方法再進入的（同時的）調用（給后來調用的方法拋出異常，告訴它當前讀取器或寫入器正在被占用）。然而，同一個插件的多個實例同時進行操作是必須要支持的。出于簡潔的目的，接下來我們只針對讀取器插件進行討論。
完全支持并發調用要求讀取器將它所有的狀態信息（例如當前的輸入源）綁定到一個獨立的狀態對象中，從而工作中的方法可以使用另外一個獨立進程修改了的下次操作使用的狀態信息繼續工作。
相比于強制要求每個ImageReader用這種方式追蹤保存他們自己的狀態，倒不如簡單地要求應用程序在需要多線程操作的時候實例化多個相同ImageReader類的實例。這意味著每個ImageReader的狀態必須只使用非京臺實例變量來保持，這對插件開發者來說應該不算是個負擔。