Paw Robot小试牛刀，却未见庖丁解牛（三）

    说的这么热闹，好像这次合作要谈成。那为什么是“未见庖丁解牛”呢？有标题可见，Paw Robot应该是没有被K公司所接受呀
。
    结果的确是这样，在今日上午10时许，K公司的人员正式通知我们，本次将不选取我们的方案，以及相关产品，还很有礼貌的附加一句，等下次有合适的机会，再谈。

   为什么会出现这种结果？我们的谈判技巧不够，还是K公司里认为我们就是不靠谱。在会谈中，有两处也许是我们做得不好的地方。

    其一，在与K公司第二次会晤是，K公司多次问及，我们能抓取哪些站点时，我们没有很好的从正面回答，我们的回答是，CCTV和各个卫视都没问题。当时我们是这样考虑的。不管各个站点发布的视频是什么格式，无论是*.mp4、*.flv、*.3gp等等，我们的抓取策略是从传输协议着手，这些千奇百怪的视频格式，最终会落在HTTP、RTMP、RTMPE三类传输协议上。Paw Robot就可将这些协议装有的视频节目还原出来。

   很遗憾，K公司的人员可能看到我们连媒体格式的后缀名，都背不全，心中暗想：别不是水货吧！可是我们没有意识到这点，还是大谈特谈 HTTP、RTMP。虽然事实上是：拿住了协议的内容的反响解析，就能轻松的还原各种视频文件，但是K公司的人员却不看重这一点。我再罗嗦一句，国内各个大小视频站点（P2P除外），前台技术千奇百怪，我不多说，后台服务器发布视频，采用的协议策略：HTTP，占99.998%，RTMP，占0.001%（我只见CCTV《百家讲坛》的某几期节目，以此发布），RTMPE，占0.001%（我只见sohu的独家美剧，以此发布）

   K公司一定要我们列出可以抓取节目的清单，最后我们去了一封email，列了六百多个节目的清单。请注意是600多个节目，节目可不是电影，电影，一部了事。节目有可能天天都有，像新闻类的节目，一年365天，做个乘法，节目量是巨大的。

   其二，我们这注重后台抓取，没注意前台界面。当时K公司提出，最终产品是否能查询？当时我们想，Paw Robot就是按照母站点个各个节目清单，按照日期，逐个建立文件夹，并将其存盘。这就已经是天然有序了，还花功夫，做这种重复开发，何意？

    用户的心里一定是要搞清楚的。这是我们的一点教训吧。我们能做得比上一家好，K公司认为是应该的。但是上一家有的功能，无论是否有用，若我们没实现，对不起，那就是不足的表现。

    K公司也许是考虑了这些，Paw Robot也就没有被采用。

    一些遗憾，只能蓄积力量，再战！