odoo原生的web框架虽然很主流通用，但一些特殊的需求还是要用传统c/s客户端来完成最佳，比如在工控机、工位平板、触摸屏立式一体机上专门针对SOP量身定制超高效率的批量作业系统。
python技术栈开发桌面端的最大优势是与odoo服务端同个语言体系，可共享相关生态与基础库，大量代码可以直接复用，xmlrpc远程调用方式也非常成熟，只是GUI图形用户界面工具包方面的选择有些取舍。
PyQt是很强大的，但是由于多年采用GPLv3协议而不好过度商用，权衡利弊最终根据实际场景定夺，如需要轻量级部署或者兼容老操作系统就使用原生的Tkinter，现代设备则大胆的选用最新版本的PySide来构建丰富多彩的odoo终端应用。
OdooForm，是全端原生自由表单和后台任意模型字段的映射组合连接器，自此欧度低代码前端应用和无代码系统生态总算顺利会师了
odoo通用移动端的研发适配是一项长期的系统工程，多少年来国际国内不少个人和组织都尝试开发过，但往往都是起个头打个水漂后就停留在欧度历史长廊里了。这些结果，renjie.me也假设性地分析过，可能是基础设施的日常迭代太过枯燥或者技术债务的不断积累达到瓶颈，也可能是相关的项目结束以及没有持续稳定的现金流烧不起这看不到头的吞金巨兽：）
之前还有一个共性就是大家都只是围绕着OpenERP的业务层次进行定位，app仅仅是原有内部管理系统在移动互联网上的延伸和扩展，没有也能将就用web。从技术角度，只是用平台原生的新语言和UI重写替换了标准web模块里的js逻辑、css样式和qweb界面，有些甚至还是用的h5混合开发技术来冗余重构。
针对上述种种问题，odooapp的产品开发决定走一条从外部全网推广包围核心erp业务的不寻常路。即优先实现website系列模块的public功能对接创新，最后才会对内部业务模块的user应用进行兼容支持。这个策略从非主流的浅水区开始，业务场景相对单纯有趣更独特，且odoo所改即所见的热更新优势更容易在互联网流量营销这个新领域发挥到炉火纯青高境界。
odoo是一个庞大的国际分工产业链，各种背景的爱好者都可以在这个链条中找到自己的归属。经过七年之痒的磨练，renjie.me也总算找到适合的基础研究方向，准备用剩余的人生以工匠精神的态度打磨再造odoo全网通client，这是一个漫长的目标和计划，接下来会坚持分享心路和成果。
c/s架构新瓶装旧酒，万变不离其宗，都是用odoo标准的jsonrpc2.0协议接口进行所有网络通讯。只不过全端开发选型已从最早的GTK、后发的QT到了移动互联网时代的uniapp框架，其最大的特色就是还支持中国国情的小程序和快应用发布。
未来理论上所有odoo原生业务、第三方应用、一二三次开发的定制系统都能天然结合这个强大的基础设施来编译出所需平台的app。从低代码平台角度，踏在odoo巨人的肩膀上，可轻松即时动态地实施出一款免开发的全平台客户端功能应用。从软件开发工具包角度，基于封装odoo底层api和前端渲染引擎的半成品sdk，可高效省心的定制开发odoo私有扩展个性化app。
odoo自媒体系统是部署在客户拥有产权的主机或者阿里云、腾讯云的服务器资源上，日期内容无限发布无限编辑。如同宅基地自建房，有天有地装修风格灵活自如，当然不能违法是底线：）其依托odoo全网通技术将相配套的客户端小程序载体植入到各个自媒体平台，后续源源不断的内容自动化同步输入，最终打通了封闭的自媒体世界和外部资讯内容的长连接。
微信公众号、头条抖音号、百度百家号、阿里大鱼号、腾讯企鹅号等自媒体平台号则是一个个独立的SaaS账号，不同的平台都有不同的规则约束，发文数量和内容时效都有不少限制，媒体内容都存储于平台，多个平台需要自己同步。如同商业地产中的租赁户，受各种物业运营管理约束，删帖屏蔽都是小惩罚，底线是不要被封号。
最后总结两者各有绝对优势，前者主站中心化、后者独立分布式。不能互相取代，最好是互补搭配使用，将最优质的创作内容以最小化的成本进行最大化的传播、分享和搜索。
