今天照著昨天的想法，翻看了 libupnp 的 UPnP_Programming_Guide.pdf,當然還回顧了一下 upnp device architecture, 及 upnp standards, 突然發現一件事，uPnP 沒定義 Control Point 這種 device!
會有「Control Point Device」我想是一場誤會，而不是 upnp org 漏掉了。因為它把「控制」放在像 renderer 上。以我看的 ushare 搭配 djmount 來說，ushare 當然是 server 沒錯，而 djmount 若當成 client 端，它也身兼 control point 的功能: 瀏覽內容、搜尋內容、取得內容、控制內容。這怎麼說呢？以 GeeXboX 裡採用 mplayer 搭配 djmount 來說，若你想「重頭播起」，是不是就是一種控制？至於其他三個功能就不言而知。
另外說要把控制點移成第三裝置這件事，網站上還看不到 v2.0 spec 有談到。因此若就 v1.0 來說，要控制像電燈、印表機這樣的機器，似乎責任落在 renderer 上，可見這個 renderer 是被我誤解最深的地方。因此接下來該需要思考的，是現有 v1.0 的各項裝置間的關係與其運作流程。
再來說明一下昨天 djmount 看的心得雖然已經列了當時的筆記，不過 djmount 本身也有提供類似 cds, cms 的功能其實也很正常，按照 upnp spec 上所提也確實如此。只是 djmount 把所謂的 cds, cms 以 filesystem 的方式呈現，這不止提供更彈性的作法，與其他工具的搭配就變得獨立開來，算是非常聰明的。
那麼，同樣的思考邏輯是否可以套用在 ushare 上呢？我的意思是，若我們把檔案放到其指定錄，應該即時傳送出去，也就是對檔案的操作應該等同於對 uPnP 的操作。或許這想法也有其困難性，或許只是沒人去思考而已。先保留著。
最後，ushare 與 djmount 有不少共同功能，以我們的需求而言，一個同時含有這兩個功能的系統是不是可以把源碼也合併呢？當然其源碼不怎麼相容，但是合併是不是就提供我上面所提問的解答呢？
1 意見:
你的blog很有意思。
我的理解是：
control point 因该是指客户端。
server 泛指所有的设备。
貌似还没有一个比较好的controlpoint 的框架出现,
Renderer 应该集成播放器，
control point 与render集成也是一个问题，
并不是所有的upnp server 都有avtransport services ,对于这样的情况，我们又应该怎么处理播放呢。
如果只是调用外部控制API 或者通过其他的url 获取资源播放的路径，那么upnp 系统中renderer 又有何意义？
需要考虑的问题太多了，
我的email xiaosong8584@gmail.com
欢迎交流。
張貼留言