My friends, my life, my style - James S.F. Hsieh

6/25/2010

OS 與 programmer 的距離越來越遠...

為什麼我會說 "OS 離 programmer 越來越遠..." 呢? 還記得我以前一開始寫程式的時候常常會想, 物件導向不是很棒嗎? 為什麼 Windows 下的 API 都這麼難用, 雖然它還是有物件的觀念但使用起來跟真正的物件還是有些差異雖然 MFC 包裝了不少 Win32 API, 但總免不了跟 OS 打交道的機會. 後來有了 Java 跟 .NET Framework, 在他們的世界裡物件模型是一致並且可以擴充的, 這時終於讓我天真感受到 "我終於活在完整的物件導向世界中 :P" 儘管實際沒有那麼盡善盡美, 但可以確定的是在那樣的開發環境下 OS 離我越來越遠... 我想這一切都是從 Java 開始的吧...

最近開始學習與了解 Android 的軟體架構 (我好像動作都比別人慢...) 也稍微 study 了一下 iOS 的設計, 反觀現有的 Windows. 有個共通的特點就是這些開發廠商都想慢慢的隱藏 "OS 的細節與耦合程度", 以微軟來說 COM 與 .NET Framework 提供了遠多於 Windows 本身豐富的元件, 也將一些生澀的 Win32 API 包裝成好用的物件, 所以 programmer 在 .NET 的環境下使用 P/Invoke 打交道的機會就越來越少. Android 也是個有趣的例子, 大家都知道 Android 底層是 Linux kernel, Google 在 Linux kernel 建構了變形的 Java VM 稱 Android Runtime 與 Application Framework 來增加 programmer 的生產力, Application Framework 是一群 Java 的元件並且描繪出 Android 上為了 mobile 特性自有的 programming model, 有了這層 Runtime, programmer 就不需要顧慮他的軟體到底跑在哪一個硬體平台 ARM or x86..., Apple 的 iOS 與 MacOS 則是在 Linux/FreeBSD 上以 Objective-C 的方式提供了 Cocoa, Carbon 與 Java 等 Application Framework, 目的也是一樣加速軟體的開發. 

我想這就是近幾年 OS 的發展趨勢 "提供統一且豐富的元件加速軟體的開發", 以往的 OS 著重如何高效率的使用硬體, 而現經則是重視怎樣提升 OS 上軟體的開發速度. 畢竟一個 OS 的成功與否是取決於上面有多少 Application. 

6/22/2010

2010 06 19 加羅湖登山口之旅



6/01/2010

Media Library Engine 2.0


It is a file-based media content management service that provides query/access, management, and tracing APIs. Windows applications can search, manage, and sync content with MLE2. It includes a daemon which syncs metadata and thumbnails between database and file system in background. MLE2 database back-end is SQLite engine. Comparing to Google Picasa cataloging engine, MLE2 can handle more files (10K~100K files) than Picasa, and they have similar performance for cataloging and search. In addition, it provides a schema-free metadata system to store complex metadata. It supports multiple applications or instances to concurrently access library. MLE 2.0 also supports primary features such as:

 Support multiple libraries in concurrent.
 Support high performance query, full-text-search, grouping and paging; MLE can handle a query to search 100000 ~ 250000 files less than 1 sec (depends on HDD and CPU).
 Support bulk operation to modify library.
 Support file time and size stacking
 High throughput thumbnail system which supports three levels pixel, 96x96, 160x160, and 480x480.
 Support applications to trace change of files.
 Extensible metadata and tags model, applications can define customized metadata and tags for special purpose.
 Extensible fault-tolerable media parsing framework, applications can implement multiple media parsers to support customized file formats. MLE includes a default media parser which supports JPEG, PNG, and BMP format based on Microsoft Windows Imaging Component.
 An async message channel between MLE and all clients. MLE uses that to notify change notification, and applications can use it to communicate each other.

I designed and implemented whole engine.