基于手机遥控的远程打印

2009/11/19 | 23:23 | 分类:Web与移动平台 | 标签: | 682次阅读

  场景:假设实验室的打印机距离你的工位比较远,现需要打印一些文章,但不知道打印机里有没有放纸、是不是合适的纸(A4/B5;新纸/旧纸反面)。贸然打印有可能造成浪费,而如果把合适的纸拿过去放进打印机再回来发送打印命令则需要跑两个来回,中途别人还有可能发送打印命令把你的纸给用了。懒人有懒道,要是能在打印机旁遥控电脑就好了!想想用什么做遥控器呢?身边最好找的远程通信器件应该是手机了。于是,我们来实现基于手机遥控的远程打印(以 Windows 环境为例)——
  我的手机可以使用语音、短信、红外、蓝牙、GPRS 等通信手段,软件支持 Email、MSN、Gtalk、Fetion 等应用。考虑到成本,排除语音和短信;考虑到距离,排除红外和蓝牙;Email 没有实时性,也排除;剩下三个 IM,其中基于 Jabber 的 Gtalk 由于其简单性和开放性,成为了我的首选。
  接着考虑如何操作应用程序进行打印。对于 Windows GUI 的自动化操作,AutoHotkey (AHK) 大神当然是不二之选。
  现在可以动手了。首先建立一个 Jabber Message Handler 来接收手机 Gtalk 客户端发来的消息。如果收到事先定义好的某个消息,则通知特定的应用程序执行打印操作。这种简易的 Handler 用 Python + xmpppy 实现即可,代码如下(gthandler.py):

  1. import os
  2. import xmpp
  3.  
  4. def msgHndl(clnt, mess):
  5.     text = mess.getBody()
  6.     user = mess.getFrom()
  7.     if user.getNode() == 'xxx' and user.getDomain() == 'linjian.org' and text.startswith('p'):
  8.         os.system('doprint.ahk')
  9.  
  10. if __name__ == '__main__':
  11.     login = 'yyy'
  12.     pwd = 'zzz'
  13.     clnt = xmpp.Client('linjian.org')
  14.     clnt.connect(server = ('talk.google.com', 5223))
  15.     clnt.auth(login, pwd, 'botty')
  16.     clnt.RegisterHandler('message', msgHndl)
  17.     clnt.sendInitPresence()
  18.     while clnt.Process(1):
  19.         pass

  这段代码很好理解。Handler 端使用“yyy@linjian.org”账号登录 Gtalk,如果收到来自手机端联系人“xxx@linjian.org”发来的“p”消息,则执行 doprint.ahk 脚本。该 AHK 脚本负责向应用程序发出打印命令(这里是以 Microsoft Word 为例的,向 Word 发送 Ctrl-P 并回车,即可使用默认打印机来打印文档),内容如下:

  1. IfWinExist MyDoc.doc
  2. {
  3.     WinActivate
  4.     Send ^{p}{Enter}
  5. }

  好了,现在打开 MyDoc.doc,再运行 gthandler.py,然后在手机上登录 Gtalk,从“xxx@linjian.org”向“yyy@linjian.org”发送一个“p”,看看有没有效果?当然,实验时可以先用 Ctrl-G 之类不浪费纸的命令做测试。
  这就是程序员,本来可以通过内线电话或免费的 VPMN、利用社会工程学手段解决的问题,也要设法把它程序化了。这到底是折腾呢,还是不折腾呢?但至少有一点是肯定的:脚本的优点是一劳永逸。

Windows Live 和 Google 账号的一些差别及其对创建个人统一账号的影响

2009/07/04 | 23:47 | 分类:Web与移动平台 | 标签: | 1,376次阅读

注意:以下论断仅针对目前阶段(2009年7月4日)观察到的 Windows Live 和 Google 服务而言,只代表用户可见的现象,不说明其实现的本质;只说明现状,不代表未来可能的变化。

1. 有关使用非 Hotmail 邮箱注册 Windows Live ID 或使用非 Gmail 邮箱注册 Google Account

1.1.M. 使用原有(非 Hotmail)邮箱注册的 Windows Live ID 与在 Windows Live 网站通过注册 hotmail.com / live.com / live.cn / msn.com 等邮箱得到的 Windows Live ID 的使用范围基本相同,可以直接使用 Messenger、SkyDrive、Spaces、Photos 等服务,只是没有 Hotmail 邮箱(注意:微软启动 Live 战略以后,“Hotmail”的概念泛指一切 Windows Live 邮箱,不限于“hotmail.com”后缀的)。可以认为,通过注册 Hotmail 邮箱得到的 Windows Live ID 只是比用自己原有的邮箱注册的多得到了一个免费邮箱。如果用原有邮箱的 Windows Live ID 登录 Hotmail,会被告知需要开通 Hotmail。

1.1.G. 使用原有(非 Gmail)邮箱注册的 Google Account 与通过注册 gmail.com 邮箱得到的 Google Account 的使用范围基本相同,可以直接使用 Calendar、Documents、Reader、Groups 等服务,只是没有 Gmail 邮箱和 Gtalk 即时通信功能。如果用原有邮箱的 Google Account 登录 Gmail 或 Gtalk,会被告知需要开通 Gmail。

1.2.M. 在已登录原有邮箱注册的 Windows Live ID 后,根据提示开通 Hotmail,相当于重新注册了一个全新的 Windows Live ID,新账号可以使用所有 Windows Live 服务。这个 Windows Live ID 与原先的那个没有任何关联,可以分别独立使用。二者的 Messenger、SkyDrive、Spaces、Photos 等数据独立、互不干扰。

1.2.G. 在已登录原有邮箱注册的 Google Account 后,根据提示开通 Gmail,相当于在原有账号基础上增加了 Gmail 和 Gtalk 服务。这时账户的主 Email 地址自动修改为新的 Gmail 邮箱,原来的邮箱则变成了本账号的关联邮箱。关联邮箱可以同 Gmail 邮箱等价地登录 Google 的各项服务;在部分服务(如 Groups)中,可以使用关联邮箱作为自己的联系方式。但一旦注册了 Gmail,在 Google 的多数服务中就会用 Gmail 邮箱作为用户身份的唯一对外标识。在此之前用户创建的数据不受影响,只是账户名称变了。用户可以解除关联邮箱,解除之后旧数据不会丢失。但需要注意,如果解除关联邮箱之后重新手动关联,部分服务(如 Groups)无法使用新的关联邮箱。

2. 有关 Windows Live Admin Center 和 Google Apps 服务

2.1.M. 在 Windows Live Admin Center 使用自己的域名开通服务,旗下用户得到的服务与在 Windows Live 网站通过注册 Hotmail 邮箱得到的 Windows Live 服务完全一致。自己域名的邮箱就是 Windows Live ID,邮箱后台也是由 Hotmail 提供支持的,名称也叫“Hotmail”。这相当于在 Windows Live 原有的 hotmail.com、live.com、live.cn、msn.com 等域基础上,增加了用户自定义的一个域。

2.1.G. 在 Google Apps 使用自己的域名开通服务,旗下用户得到的服务与一般的 Google Account(无论使用原有邮箱或注册 Gmail)并不相同。自己域名的邮箱并不是可以登录 Google 各项服务的 Google Account,而是仅仅能登录本域的一个账号。Google Apps 相当于为企业、学校等用户群体提供一个适于内部使用的、相对独立于 Google 公共服务平台的“小 Google 服务平台”。在这个小平台中,提供有限的几项服务,如 Mail、Calendar、Documents、Sites、Gtalk 等,不包括 Reader、Groups 等。这些服务体现“内部”特色,在逻辑上与 Google 公共服务平台隔离,例如 Mail 被命名为“[你的域名] Mail”而非“Gmail”;但这并不影响域内用户与其它 Google 用户(包括其它域下的 Google Apps 用户)进行有限的互通,例如可以与跨域的 Gtalk 联系人聊天、共享 Documents 上的文档等。

2.2.M. 通过 Windows Live Admin Center 得到的自己域名的 Windows Live ID 与使用默认域名的 Windows Live ID 处于平行位置,功能等价,没有带来新问题。

2.2.G. 通过 Google Apps 得到的自己域名的账户并不是 Google Account,因此如果用户需要使用完整的 Google 服务,需要另外注册 Google Account。如果用户使用基于 Google Apps 的自己域名的邮箱注册 Google Account,可能带来一些微妙的问题:

2.2.G.1. 总体上说,这与 1.1.G、1.2.G 节所述的“使用原有(非 Gmail)邮箱注册的 Google Account”相似。

2.2.G.2. 对于 Documents 服务,用户分别拥有“Google 公共服务平台”和“本域服务平台”上的两套版本,分别在不同的界面使用不同的密码登录,数据独立。如果注册了 Gmail,则 Gmail(Mail)、Gtalk 服务也类似地维持两套版本。

2.2.G.3. 对于 Calendar、Sites 服务,本质上也有两套版本。如果没有注册 Gmail,则会因账户重名问题只能在优先注册的平台上使用,第二套版本无法启用;如果注册了 Gmail,则可以保证两个平台上拥有不同的账户名称,两套版本可以并存,数据独立。

2.2.G.4. 对于 Reader、Groups 等“本域服务平台”没有提供的服务,可以在“Google 公共服务平台”上使用,不存在多版本问题。

3. 总结及对创建个人 Windows Live / Google 统一账号的建议

3.1. Windows Live 对非原生邮箱账号的处理比 Google 更简单、更易于理解一些,区别一在能否直接使用即时通信工具,二在注册原生邮箱之后对原有账号的影响。我们可以通过单独注册 Gmail 邮箱的方法让 Google 实现类似 Windows Live 的“双账号”行为,但不能在 Windows Live 中为非原生邮箱账号添加额外的 Hotmail。

3.2. Windows Live Admin Center 与 Google Apps 是两个定位有所不同的产品,Windows Live Admin Center 强调用户域与 Windows Live 平台的相对统一,而 Google Apps 强调用户所属组织的独立性。它们的功能行为满足了不同类别用户的需求。

3.3. 对于企业、学校等有特殊需求的用户,或者仅偏好于 Windows Live / Google 一方的用户,以及对账号不在意或不愿公开的用户,不在本文讨论范畴之内。

3.4. 对于追求“使用并公开统一账号,访问 Windows Live / Google 服务”的用户,建议方案为:通过注册 Gmail 邮箱得到 Google Account,享受所有 Google 服务;然后使用这个邮箱注册 Windows Live ID,享受 Hotmail 之外的所有 Windows Live 服务。因为对外统一接口是 Gmail 邮箱,所以 Windows Live 上的联系人可以直接联系到用户,无须经过 Hotmail 邮箱。相反地,如果首先通过注册 Hotmail 邮箱得到 Windows Live ID,再用此邮箱注册 Google Account,则无法使用 Gmail 与 Gtalk。如果用户不在意 Gtalk,则此方案也可行;否则此方案不佳,因为如果用户在此基础上注册了 Gmail 或 Gtalk,多数 Google 服务中的用户账号会变化,不符合“统一账号”要求。

3.5. 对于追求“使用并公开统一的个性化(自己域名的)账号,访问 Windows Live / Google 服务”的用户,没有像上面那样完美的方案。建议的两种方案为:

3.5.1. 使用 Windows Live Admin Center 开通自己域名的邮箱,即可享用所有 Windows Live 功能。使用这个邮箱在 Google 注册账号,即可使用 Gmail、Gtalk 以外的几乎所有 Google 服务。如果用户不在意 Gtalk,则到此为止。如果用户在此基础上注册了 Gmail 或 Gtalk,多数 Google 服务中的用户账号会变化,不符合“统一账号”要求。不过用户也可以在 Google 之外使用自己的服务器搭建 Jabber 服务,与自己的域名绑定,现实与 Gtalk 的互通,但这提升了实现成本和技术难度。

3.5.2. 使用 Google Apps 开通自己域名的邮箱,即可享用部分 Google 服务(关键是有 Mail 和 Gtalk);然后使用这个邮箱注册 Windows Live ID,享受 Hotmail 之外的所有 Windows Live 服务。再使用这个邮箱注册 Google Account,享受其它 Google 服务。注意不要开通 Gmail,原因同上,且此举是无法恢复原状的!此方案的缺点在于 2.2.G 节所述的部分服务双版本共存或双版本冲突的问题,使用时需要格外注意,防止混淆。

3.6 对于新启用统一账号的用户,3.4、3.5 节提出的方案可以在一定程度上满意其需求。但对于已经在不同平台上使用了不同账号的用户,迁移到新的统一账号上来却是不方便的。主要的问题是用户数据无法同步迁移。目前 Windows Live 和 Google 提供的关联邮箱功能,主要解决的只是多账号登录问题,没有太关注内容同步,这也许是它们下一步有必要努力的方向。

附录A. 我个人的统一账号迁移方案:基于 3.5.2 节方案,前两个步骤相同,但没有注册新的 Google Account 和 Gmail。访问 Google 服务仍然使用原来的 gmail.com 账号。主要的考虑是:

A.1. 我原来在 Windows Live 上使用的服务以个人存储为主、人际交流为辅,内容易迁移;即使不迁移也无妨,因为大多是自己使用,不对外公开交流。因此这个账号可以停止维护,只增加必要的邮件监控或转发。

A.2. 我原来在 Google 上使用的服务以人际交流为主(如 Reader 和 Documents 上的共享、Groups 中的群组和帖子),如果迁移,对个人和其他联系人都有一定的时间和劳动成本。

A.3. 我关注的统一接口的三个要件是 Email / MSN / Gtalk,这一方案满足了此要求。缺陷只是在访问 Google 服务的时候没有使用统一的账号,但这并不影响对外公开的接口。且 Google 双平台 cookie 独立,方便同时登录 Google Account 和 Google Apps 账号,互不干扰。

上面大折腾,下面小折腾——启用新的 Email∕MSN∕Gtalk 账号

2009/06/26 | 12:02 | 分类:默认分类 | 标签: | 1,899次阅读

  前天和昨天中国互联网可够折腾的了,这些折腾再次警示我们网络上可能存在的风险。上面大折腾,我在下面也小折腾了一下,启用了新的、统一的 Email/MSN/Gtalk 账号:
  上面大折腾,下面小折腾——启用新的 Email∕MSN∕Gtalk 账号
  麻烦朋友们在 IM 或地址簿中加入这个新的账号。
 
  启用这个新账号,出于以下考虑:
  1.原 MSN 账号基于“.cn”域名,存在潜在的安全风险。
  2.原 Gtalk 账号名称过长,不便他人记忆。
  3.原“@gmail.com”邮箱存在一定的受阻风险
  4.我原先对外公开的 Email 较多较杂,不便统一处理邮件。
 
  新账号的技术方案:
  使用 Google Apps 建立自定义域名的邮箱(基于 Gmail 系统)和 IM(即 Gtalk)服务;使用这个邮箱注册 Live ID,即可开通 MSN 服务。
  顺便说一下,原来的“@linjian.cn”的邮箱和 IM 使用的是微软的 Admin Center 服务。与 Google Apps 类似,它提供了基于 Hotmail 的邮箱和基于 MSN 的 IM 服务。但 Google 不允许使用 Gmail 和 Google Apps 账号以外的 Email 地址作为 Gtalk 账号(虽然可以使用第三方 Email 注册 Gtalk 别名,但别名只能用于登录,在好友处显示的仍是一个“@gmail.com”结尾的、不能收发邮件的 jabber 名称。而且这一特征只能在英文版 Gtalk 上使用,中文版 Gtalk 和多数第三方客户端不支持)。
 
  新账号的优点:
  1.Email/MSN/Gtalk 统一的入口地址,便于发布和记忆。
  2.公开单一的邮箱,处理与朋友往来的邮件,减少管理邮件的时间开销。当然,处理工作业务、重要数据的邮箱并不统一到这里,还是要用独立的。
  3.安全。使用自己的域名,可修改 MX、SVR 等记录,不受制于服务提供商。即使 Gmail 相关域名被劫持,自定义域名的邮件收发也不受影响。即使 Google 相关的 IP 被过滤,我也可以在不改变账号的前提下更换邮箱服务器和 jabber 服务器,通信不受影响。自己的域名被劫持相比 Google、Live 被“肃整”的概率要小一点。
 
  新账号的缺点:
  1.Google Apps 账号不能使用完整的 Google 服务,它可以访问 Calendar、Docs 等,但不能登录 Reader、Groups 等。所以我仍然需要使用原 Gmail 账号登录上述服务。不过这对面向他人的“统一入口地址”影响不大,只是自己麻烦点;好在 Gmail 和 Google Apps 的 cookie 是独立的,可以同时登录互不干扰。
  2.联系人批量转移是个麻烦事,好在 MSN 和 Gtalk 都可以批量导入导出纯文本的联系人列表。需要各位联系人确认一下我的添加请求。
 
  备注:
  目前正在使用“@linjian.cn”的 Live ID 的朋友请不要担心,只要没有不可抗拒的因素,我不会停止对 linjian.cn 域名的支付和维护;只要微软的 Admin Center 服务继续免费提供,我就不会停止使用 linjian.cn 上的 Live 服务。除了对个人姓名域名的保护性注册因素之外,我们也必须认识到:虽然目前放在美国的域名比放在国内的域名(尤其是“.cn”)要保险一些,但美国毕竟是我们的潜在对手。万一中美关系有大事变,不排除中国人在美国的域名受到威胁的情况。所以,“.cn”域名可以认为是一种战备资源,适当的时候可以显示其价值。

闲扯Gtalk

2009/02/28 | 16:47 | 分类:IT杂谈 | 标签: | 831次阅读
  1. 我不太理解的一点是,Google为什么不向用户强调XMPP互联互通的特性?Gtalk刚刚推出的时候,外界普遍猜测Google有望把互通性作为最大的亮点,利用XMPP的杀手锏迫使现有的IM市场转向开放。但事实上Gtalk只在添加联系人的过程瞬间显示它可以和jabber.org等互通(网速快的话根本注意不到)。Google在面向用户的说明页面(http://www.google.com/talk/about.html)上只提到客户端的可替代性,并不强调服务的互通性。在面向开发者的页面(http://code.google.com/apis/talk/open_communications.html)也只用偏技术的语言说明了这一特性。对于多数Gtalk用户来说,他们也许并不清楚Gtalk可以和其它某些IM不加任何设置就能互通。当然,那些IM的影响力不够大可能也是一个原因。Windows Live Messenger和Yahoo! Messenger、Gtalk和AIM,这种保留现有协议的“曲线”互通则成了IT媒体关注的焦点。显然,市场因素胜过了技术因素。但Google理应是一家有实力推动IM标准统一、开放化的公司,它没有像人们猜想的那样力推XMPP,或许真的是商业公司的本性造成的?在这个年代,标准的推广是多方利益的博弈。改变像IM这种与既有用户严格绑定的应用的前景不容乐观。
  2. 有关Google Apps用户的Chat设置。对于使用自有域名开通的Google Apps Chat用户,要设置与其它XMPP的用户互通,需要给域名添加SRV记录,详见(http://www.google.com/support/a/bin/answer.py?hl=en&answer=60227)。要使用第三方IM客户端或网站(如Pidgin、JWChat)登录Google Apps Chat的账户,需要设置连接服务器为talk.google.com,端口5222,详见(http://www.google.com/support/a/bin/answer.py?hl=en&answer=49147)。后一条没有放在Google Apps Help中显眼的位置,需要搜索才找得到。尽管Google Apps一般是由IT管理人员来注册和设置的,但给人整体的感觉就是Gtalk没有走大众路线。
  3. 这段日子Google Talk Chatback Badge以及针对Google Apps的Google Talk Gadget总是“Not Found - Error 404”,不知道Google还有没有兴趣把这些东西做下去了。Gtalk开发博客(http://googletalk.blogspot.com/)更新频率的下降从一个侧面说明了问题。Google从来没有像微软或雅虎那样大张旗鼓地宣传自己的IM,也没有太多地说明它的市场定位。发布三年来,小的改进不少,但从界面到功能一直未见大的变化。Gtalk的用户数量也不及那些对手的零头,不过相对集中在IT圈中,存在一定的忠实用户群体。不知道Google的葫芦里卖的是什么药,是想让Gtalk顺其自然的发展,还是在酝酿着某一天突然暴发?
  4. 较新版本的英文版Gtalk是可以使用账户关联的其它E-mail地址(非Gmail或Google Apps账户)登录的,登录之后显示的是用户的主E-mail地址。而最新的中文版Gtalk(1.0.0.105)却不支持非主E-mail地址登录。从Gtalk登录界面就可以看出来,英文版叫“Username”,而中文版叫“Gmail用户名”。Google的本地化策略还是比较有趣的。
  5. 不知道Gmail和Gtalk什么时候才会去掉“BETA”。