博客

关于 Mobile Web 开发中的 Content-Type Header

偶很久以前发布在内部 wiki 上的, :)

参考:http://www.developershome.com/wap/xhtmlmp/xhtml_mp_tutorial.asp?page=mimeTypesFileExtension

XHTML MP 可以使用三种文档类型

  1. application/vnd.wap.xhtml+xml

  2. application/xhtml+xml

  3. text/html

OMA 推荐的标准 MIME 类型为 application/vnd.wap.xhtml+xml . 在某些手机浏览器上,必须使用这个类型才能正确显示

application/xhtml+xml 也可以采用,这个是 XHTML 建议的文档类型 (W3C 标准)

但是,某些情况下可能还是需要返回 text/html 类型,这是因为有些老的浏览器不支持 application/vnd.wap.xhtml+xml 或 application/xhtml+xml,比如 IE 6 就会弹出一个对话框让你打开...

【既然我们是提供移动体验,为什么还考虑 IE6 这种东西呢???我的想法是,人们有可能在别的媒介上看到 m.vip.sohu.com 或者 m.mail.sohu.com 这样的域名,他们有可能会用 IE 打开来看看,对于这种情况,我们最好是让他能在桌面浏览器上也了解到这个页面的功能,而不是粗暴的让他下载一个 xml 文件。 (qyb)】

解决方案是:检查用户浏览器发过来的 Accept,如果它能支持 application/vnd.wap.xhtml+xml,那么 response Content-Type header 就是 application/vnd.wap.xhtml+xml ;如果能支持 application/xhtml+xml,那么 response Content-Type header 就是 application/xhtml+xml;如果什么都不支持,那就返回 text/html

另外,页面必须是 UTF-8 编码, GB编码的 XHTML 在某些手机上无法识别

Topic: 技术

闪电邮箱移动版本功能更新

在我们三周的产品更新计划里,10月15日这次发布对最终用户来说最大的增强就是移动访问能力的改善.

大概半年多前,我们已经去掉了对 WML/WAP 1.3 的支持——当时得到的一个数据是现存的手机有 80% 支持 WAP2.0,在售的手机有 95% 支持 WAP 2.0。这次进一步增加了色彩和图标的使用,让用户得到更佳的视觉体验,而且针对智能手机也做了一些优化。

无图无真相:

  • 微软刚刚发布的 Windows Phone 6.5
  • 这是 Palm Pre/WebOS, 传说电信要定制?
  • Android,也就是中国移动的 OPhone
  • 当然少不了iPhone,中国联通

GMail 大概维护了有4套webmail UI:普通Ajax/基本HTML/WAP/Mobile Ajax 。 我们精力有限,可以肯定 Basic HTML 不会提供了,或者说我们的 WAP 版本也算一个 Basic HTML ,在 Ajax Load 过程中,已经在提示用户可通过 m.mail.sohu.com 进行访问。我们会继续完善我们的这两套 UI, Mobile Ajax 有兴趣,但还没有规划。

最后,mail.sohu.com 这个入口是能够识别绝大多数的移动浏览器并自动重定向到移动版本 m.mail.sohu.com 上的,如果您的手机不是这样,希望能告诉我。//beg

下一次发布是 11/5

Topic: 商业 技术

xorg 也计划每半年一次的发布以及类似 Linux 的代码维护模式

由于这次 xorg 1.7 跳票十分严重,Peter Hutterer 建议对以后的版本开发以及发布进行改进,主要就是两点

1. master 只对 release manager 开放,和 Linux 开发模式类似——每个人在自己的分支上工作,由 Linus 负责合并其他程序员提交的 patch

2. master 维护阶段分成3步,merge window、bugfix、release freeze。他目前建议是 3M + 2M + 1M 的时间段,这样正好每半年做一次发布,也和 GNOME、Ubuntu/Fedora 的发布节奏吻合。

这种基于deadline的发布比起基于feature的发布来,商业性的意味更强一些,而少了工程师理想化的色彩....

最后要说的是,我注意观察了一下 QQ Mail 的更新周期,大概是每三周一次。现在我们团队正在实验类似的更新模式,对互联网产品来说,这种模式还是值得借鉴的。

Topic: 技术

再见理想

这个国庆假期是在江西过的,去了永新县的三湾,上了井冈山,今天又来到打响中共武装革命第一枪南昌,几乎可以算是一次“红色旅游”了

永新有名的是狗肉,有回一大早就在房里听到外面呜呜屠狗的声音,都说狗的智慧足够高,不知道狗狗们生活在如此的环境里会怎样发展身心,反正觉得这里的狗好像都挺和善。

永新县出了4位解放军中将和几十名少将,但是将军们的塑像和浮雕只是在给贺子珍纪念馆做陪衬。看起来他们为中国革命做的贡献皆不如这位女士,真是神奇的唯物史观

在三湾纪念馆里,陈列了经历三湾改编的几位将军的画像,其中有林彪和黄永胜。在井冈山烈士纪念馆里,2人则消失在朱彭陈罗谭粟等将星中。

为了接待全国参观学习的党员们,特别是为了接待中央和军队大员们,吉安地区规划出一个“井冈山市”,甚至市领导屈尊来兼任这个县级行政区的长官——我猜是为了名正言顺的全程陪同上级而不至于显得不务正业。不管怎么说,这个旅游点建设得不错:火车站极好,相比较看,通往这儿的火车就显得分外破旧了;市区是在茨坪这个海拔1000多米的地方凭空盖出来的,干净整洁。总体而言,井冈山很适合度假,我的意思不是旅游(vocation vs travel);来这个安安静静住个几天就好,景点不过黄洋界等红色故地,没有太多逛头。

贴士1:我们在井冈山一直是在革命博物馆南边的南苑宾馆二楼餐厅吃饭,价格还算公道。它好像主要业务是晚上的团餐,如果晚饭得早点去,否则就招待不上了。

贴士2:在南昌是亲戚安排的百瑞四季酒店,四星。我们住的标准间貌似网上的报价是388,个人觉得还算物有所值。现在就在用它的免费宽带写blog。百瑞是杭州的酒店管理公司,2楼的餐厅的杭州菜很好吃。晚上赣江边秋水广场的音乐喷泉值得一看。

南昌最有名的景点应该是滕王阁了,可是我很怀疑它只是为了验证《滕王阁序》才有不断重建的必要。明日登阁,不晓得会否看到一堆游客长吟落霞与孤鹜齐飞?

Topic: 生活

很尴尬的成为 SSL 中间人攻击的教材

见:http://wuhongsheng.com/it/2009/09/ssl-hijack/ ,现在这个所谓的漏洞已经得到修补,暂时不打算跨省追捕这个吴洪声

附带宣布一下,继 vip.sohu.com 提供 https 服务之后,mail.sohu.com 也计划提供全程加密的 https 连接。技术在 vip.sohu.com 上已经证明可行——主要是灵活处理 URL,在普通模式下静态资源比如图片/JS使用 CDN;在 https 模式下使用 https://mail.sohu.com。

Topic: 商业 技术

2.6.32 的 scheduler 变化

引用:http://lwn.net/Articles/352863/

"kernel 2.6.32 前瞻"里提到过,在和 BFS 进行了对比测试后,程序员们将在 2.6.32 里修复原来 CFS 的一些问题,这里都有些什么呢??

首先是 NEW_FAIR_SLEEPERS 特性缺省会被禁止掉。这个功能是当一个进程结束睡眠返回运行队列的时候,gives it a small runtime credit。现在看起来这个东东实现得有些问题,未来解决后也许会重新打开。

该特性实际上现在就可以关掉。CFS scheduler 提供了 15 个 bool 值来控制其运行(原文是说它有32768种组合),我们只需要简单的

echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features

或许你的桌面就运转如飞了。

还有一个变化就是 Child-runs-first。【虽然我们在操作系统课里学到,fork() 之后的代码段究竟是 parent or child 首先执行是不可知的,但实际上操作系统的行为绝对不是完全随机的,我猜在 CPU 不那么多的系统上更是如此。】最近 Linux 的实现里,子进程会被安排优先执行,从概念上来说这样设计是对滴,因为通常意义上子进程的工作更重要;但这个有可能影响性能:在此时父进程的上下文信息被当前CPU、TLB保持,立即切换到子进程会有些延迟。在 kernel build 测试里,Parent-runs-first 性能有了显著提高。

有人提出质疑,说这样的变动可能导致那些假设子进程会首先运行的程序异常。尽管我觉得那些不按理论规范只凭经验写程序的人碰到麻烦是咎由自取,2.6.32里还是很厚道的留下一个kernel.sched_child_runs_first sysctl调用去向前兼容。

最后是 cpuidle,为了社会和谐,现代高功耗的 CPU 都有这个 idle 功能。一方面是在低功耗模式下,切换到普通模式由于本身这个操作是相当耗能的,所以在低功耗状态下会执行得很慢;另外这种切换有一个性能损失造成延迟...甚至 BFS 也没有解决这个问题。有人已经弄出一个 patch 解决问题(具体算法去看 LWN 原文),有可能会被合并到 2.6.32 里。

Topic: 技术

kernel 2.6.32 前瞻

先介绍一下现在内核的开发模式:一开始Linus大概花2-3周的时间从其它人的git里合并代码,他肯定不可能看懂所有的代码,但我们也知道他也会拒绝那些他不太喜欢的代码;然后关闭 merge window,发布一个rc1,理论上所有的功能都freeze,剩下的只是 bugfix;这里也有例外,要看linus的心情而定,比如2.6.31的rc2里是又额外添加了新feature的;接下来差不多每周发布一个新的rc,在 7-10个rc版本之后,一个新的内核版本就正式发布了。总之现在大约是每11-13周有一个新的2.6.x出来

下面看看2.6.32

  1. 在 Greg KH 发出威胁后,微软的程序员终于在列表上开始了回应,似乎 Hyper-V 驱动还能继续在 stage 里呆着。微软必须学好怎么在 kernel 开发者社区中生存
  2. 某些程序员在和 Brain Fuck Scheduler 进行了对比测试后,发现了当前调度器中的一些问题,在 2.6.32 中会得以修正。看起来 BFS 永远也不会被合并到tree里,希望它的一些概念能给我们使用 linux desktop 带来更好的体验
  3. devtmpfs 是一个争议很大的特性,有几个人认为它很垃圾,但linus看起来不这么想。devtmpfs 又称为 devfs 2.0,好处之一是在内核自举的时候就把设备都挂到 /dev 上,节省了执行 udev 的时间
  4. DRBD... 终于也要进入内核了,事实上 devtmpfs 受到质疑的原因之一就是它对 DRBD 设备的集成. DRBD 算是一个简易廉价的存储HA实现,我知道以前 zhanzuo.com 就在用这个特性
Topic: 技术

闪电邮箱会话功能第二弹:会话计算和显示

gmail的会话合并是通过主题来完成;而且没有参考Header里的字段——做一个简单的测试:回复一封信,换一个主题,然后可以看到回复信和原件并不在一个会话里。

根据主题来确定会话是一定要有的,几个中文webmail只有163、QQ、sohu正确的实现了In-Reply-To,为了更大的兼容性必须如此。

搜狐现在的方案是,同时根据Message-ID、In-Reply-To、References,以及信件的主题来做会话的归属计算。所以在 GMail 里看到的会话和 Sohu 里看到的会不太一样。

GMail 仅仅使用主题来计算可能是优化这种情况:发信人很懒,每次写信都是从读信页面里选择回复,然后换个新主题,删除掉所有内容,而不是重新写一封邮件。我们以后是否也换成这个策略等用户反馈吧

或者可以更智能的从内容里面的引用关系、相关度去计算会话??现阶段还只能想象了。

某些情况下我们会主动 break 会话:

  1. 和第一封时间超过 30 天的 (想象一下你订了一个服务叫“今日股评”)
  2. 会话总数量超过 100 封 (太多了对阅读信件UI是一个灾难)

===============================================

有的时候,信箱里会有2封或多封Message-ID一样的邮件,最简单的情况是你写一封信给自己,这样已发送和收件箱里各有一封;或者你发一封信给邮件列表,邮件列表会重新给你寄一份。

在一个会话里看到两封一模一样的信不那么优雅,我们的规则是这样:

  1. 首先隐藏不在本文件夹的信(比如一封信发给自己,那么在收件箱中,看到的是投递过来的信;在已发送中,看到的是发送出去的信)
  2. 然后隐藏新邮件(这样也是为了防止攻击,恶意顶掉别人发的信件)
  3. 最后保证,一个会话只显示一个 Message-ID
Topic: 商业 技术
订阅 RSS - 博客 | BT的花