一如既往的看协议，画流程，分模块，然后码Code，调试，无奈之中还是有些有趣的小东西。

很纠结于网管和操作维护，各种各样的，要有SNMP，要有MIB定义，要有TR.069, 要有soap接口，要有web配置界面，要有CLI，同时要支持upnp，

再加上App自己的一堆配置文件，脚本。这一坨的东西都要和App打交道，做CM，PM，FM诸如此类，很多的接口会重复，会紊乱。

需要一个好的抽象层，既方便实时的对App的配置表做Get/Set, 批处理，也要方便的和不同的协议做接口。

这地方的数据抽象分为几类，

In Memory, 快速的运行时访问。

Local Storage, 静态和default的配置数据，同时作为仓库供内存table来snapshot。

Remote Storage，通过RPC接口来获得，更多只是协议和接口的定义。

对应SNMP，用MIB来定义，OID来访问。

对应XML，用schema来定义，用XPath来访问。

如此类推，逻辑上抽象是各种schema之间的转换，具体到object是各种访问的命名空间，path之间转换。

Path:Object:Attribute Set + 各种的Mapper 以及 Adaptor 和 Backend。

Mapper处理schema。

Adaptor处理Serialize相关。

后端来处理真正的存储和I/O, 以及网络的协议交互。

继续基于Ak来做实验。

路过张家界，时间太赶，下次再去。最美的一段路是常德到吉首的一段新的高速，漂亮的隧道，路两边的梯田，丘陵和满山遍野的油菜花。

和一班朋友跑出去，到一个没去过的地方，吹水打P，真的是很好的放松手段。

休整够了，该干活了。陆陆续续的也把一些琐碎的念头整理的差不多了，现在，当前是个暂态，抱着点些有些无的希望，准备开工，上路。

方向是没有方向。

春天这个季节很容易抑郁，最近很挣扎，挣扎于各种年龄，各种职业的人之间所进行的各种奇怪的事情的忽悠和反忽悠，决定出去散心，时间未定，地点未定，同行人员未定，没有方向。散之前，还是得想想散完了之后得干吗，各种纠结的事情还是得一件一件的做。

开源的东西，一个特点是可以嫁接不同的Backend，来获得多平台的支持，把移植的工作量变成更多是各种依赖关系，makefile脚本的修修补补。

最近一段时间在看Settop-Box的东西，做应用总是会离不开浏览器的平台。考虑如何在受限系统上让浏览器跑的更欢。

firefox和fennec是无论如何还是得看一看的，一想到XPCom和那套很强大的XUL的东东，就…https://wiki.mozilla.org/Fennec

WebKit可能是更好的选择，Owb和OpenMoko的项目也是做的很火… http://www.sand-labs.org/

对于Video这块的支持，可以通过plugin来做硬件的加速。Intel的CE和Sigma的东东现在都支持Adobe的Flash的硬件加速。

图形图像这块，嵌入式系统总是会区分各种不同的能力集，

1. 完全无加速的帧缓冲framebuffer抽象

2. 支持最简单的图片JPG，PNG.解码，基本的硬件Blit和Alpha-Blending，通过SDK提供.

3. 支持硬件加速的矢量图形原语的pipeline，SVG，OpenVG接口.

4. 支持3D pipeline的OpenGL ES接口.

所以我们看到了一堆的Backend， DirectFB的在大量的中低端支持1,2上面很流行，WebKit也有人做DFB的Backend, 更多的是在WebKit的Gtk+的后端嫁接DFB+GTK。

Clutter是个有趣的东西，最早是在Intel的Moblin项目上看到，当然，Moblin很可耻的和Nokia的Maemo合并了，他们现在叫MeeGo, 都是些很有喜感的名字。

http://moblin.org/

http://maemo.org/

http://meego.com/

Clutter本身就是一个抽象API层，一个2.5D的Container，后台可以用OpenGL来加速啊，当然也开始疯狂的做各种的Backend，越做越大，字体处理，图形，渲染都想去做。http://www.clutter-project.org/

支持4，自然会有人考虑混交了WebKit和Clutter。之前人们总是习惯于用Mesa + X11, 用SDL这个啥都有的东东来敲OpenGL。

好吧，对于一个非3D化的Settop-Box来说，真正靠谱的是视频和图片，矢量图形的加速。Flash的嵌入式平台支持一直不理想，

虽然有GNU的这个好东东Gnash，他们终于开始把整个Render和Raster都换成了AGG。

http://www.gnashdev.org/

http://www.gnu.org/software/gnash/

http://www.antigrain.com/

作为一个纯Soft的实现，一直觉得AGG最高。

说来说去，一个好的图形库，后端有各种硬件能力的支持，1,2,3,4,方便裁剪适合不同的系统，好的API文档描述和易用接口。

GTK+，ATK，Pango，Cario这一整套的东东，很好，Mozilla一直痴痴地用它，太大了。

QT很全，新的4.6支持OpenVG，OpenGL的支持也一直在完善，很好，太大了。

DirectFB不是一个图形库，更多是个工具集，粘合剂，缺少图形原语的支持。

好吧，其实最爱的还是Skia。

做一个好的UI，这些还不够。得有好的WM，得有国际化支持，字符集库，小的好用的字体渲染和Layout库，方便的控件库，不依赖于Browser的场景下，松耦合的一套实现逻辑和交互的脚本语言，LUA?

是否该借鉴下Micro-Kernel的思想，还是继续走混搭的路子。

因为Hulu，关注到Boxee这个东东，TV，Settop Box还是可耻的跑到internet上找stream了。

DeviceGuru很有意思，更有意思的是那篇:

http://www.deviceguru.com/comparing-10-free-media-center-apps/, 很详细。

顺便跑去看Yahoo！的东东，ConnectedTV和TV Widget，http://developer.yahoo.com/connectedtv/ , 热血啊。

Boxee是基于XBMC的，疑似用JS来做哪些OSD上Widget，到底是不是直接的照搬XulRunner，没仔细看。

Settop Box以前是Mips，Arm的天下，接tuner，做高清播放，做各种外设接口，做各种音视频的I/O。。。

开发总是纠结于各种SDK，各种音视频格式的兼容性，就是一个适合电视OSD上呈现UI的Player，

始终内容源是个问题，接着就开始做P2P的下载，考虑做内容推送系统，家庭局域网也开始考虑设备接入和互联，UPNP和各种Stream Server，

也有做单机应用和Web应用的，更多考虑的是一个JVM好做APP移植， 一个靠谱的Browser。

现在，接Internet，做TV Widget，做APP 分享，做Feeds， 做Social的整合。

更多还是平台的问题，硬件的，OS的，应用的。各家的芯片商提供的都是自己一套从开发参考板，Toolchain，OS，SDK，Demo APP长长的一整套。

现在，热火的Intel的CE系列芯片，强大的Android平台（好的JVM和Browser，还有OpenGL ES的支持），

有了好的平台，开始能真正的考虑要开发的应用到底是啥样的，互联网应用是啥样的。

平台的整合，支持feature的应用包括系统侧的设计也在整合。更多的Web应用，已有的那些SP内容源应该能聚合到TV上。