odoo多网站架构可以让每个站点都对应一本能实时全网发布动态更新的电子书，其每个菜单每个页面的媒体内容都可以由各种文字、图片、音频、视频、地图、HTML等基本元素所组成，一份内容最多同时可发行的载体有通用H5、安卓苹果APP，各大平台小程序和快应用等十几个展示端。
odooapp电子刊物解决方案相比传统纸质出版内容更丰富、使用更便捷、传播更高效，同时还能与用户进行交流互动和分享裂变。自出版运营成本极低，但发行平台巨广，可算是用仅有的宽带流量来圈养更多的流量用户。所有位置灵活自营各种形式的广告业务，还可以挂载各小程序平台流量主的激励广告进行内容变现。
odoo开源免费版权干净，基于python生态容易二次开发和集成上下游系统。后台支持多域名多类型多应用私有化部署，所对应前端小程序app只要每个平台一次性注册审核通过初始版本，后期即可免更新的快速增加、修改、删除所有出版物内容。odooapp助力每一种书刊都有一个全网通小程序的物联网时代尽快来临。
odoo除了可以配置app的ui渲染元素外，还可以用动作连接各平台原生功能，实现odoo从前端布局生成界面到用户行为响应结果又反馈回odoo后台的整个闭环模式。关于这些超级能力，大致可以分为操控类、浏览类、开放类、系统类：
操控能力主要指全局应用层面的，比如动态修改标题文字和主题颜色，以及app跳转app、小程序跳转小程序和相关返回控制。目前比较热门的私域免费小商店也可通过这种方式从各个公域流量入口引导过来。
浏览能力则是各种媒体类型直接播放和各种文档格式直接预览，其中不仅包括各种图片、音乐、视频等多媒体，还包括Word、Excel、PPT、PDF等可实时更新的在线文档。
开放能力全属于各平台赋能，不同的平台所赋予的功能细节都有所不同。比如应用级的在线客服和投诉反馈；用户级的手机号码、收货地址、发票抬头、地理位置等隐私信息获取；营销级的分享好友、分享群和发布朋友圈动态等推广能力。
系统能力有调用手机硬件的扫码、拍照、录像、振动、电话等基础功能，也有打开文件系统的各种相册、视频选择器，还有相关底层接口的联系人、消息、提示、弹框、剪贴板等操作。
odooapp后台控制方向子产品，需要先安装配套的移动应用，比如web_app、website_app、website_blog_app、website_shop_app等。这些以app为后缀的模块，都是继承在原功能模块的基础上，进行的移动化数据接口封装和实施规则注入，这让odoo一个实例就可以轻易快速的运营由多个平台上的多个app、小程序和快应用所组成的超级移动seo矩阵群。
这种odoo全网发布的基础架构主要是为互联网传播运营而生，因为不同的平台甚至不同的渠道都有不同的规则，就连最关键的名称都不一定能注册到一致，更不是所有内容都能在所有系统平台渠道一致性的出现，以及还有一些审核方面的差异化开关都需要app有这种动态热变更的能力。
实施差异化的维度分为平台级、渠道级、版本级。也就是说odoo可以控制最细的粒度是某个平台某个渠道某个版本app或小程序上所能呈现的原生渲染内容，这种内容又可以细分为参数类、主题类、菜单类、记录类、页面类、区块类、元素类、资源类，各种类别自由组合起来可以完成非常丰富的专业运营需求。
每个平台一次发布审核终身免更新，只要odoo实施变更，app小程序快应用所有平台所有渠道都会全网自动同步。在移动互联网这个细分流量的战国时代，祝愿所有企业在所有平台都有属于自己的全网通小程序app入口来承接各路流量，最终汇聚成传说中的私域流量来进行可持续的发展精细化的运营。
odooapp纯前端方向子产品，不需要安装任何后台应用模块，也就自然规避了odoo年复一年的大版本更新迭代所带来的变化问题。同一个app可以同时对接多个版本的odoo，也可以多个小程序连接到同一个实例的odoo，各版本之间的兼容性全部在前台分支解决，这样架构上就可以支持所有odoo版本。
这种odoo万能客户端模式几乎所有竞品都在采用，包括官方的闭源app也是这套路，接口起点都是从调用rpc的common服务version方法开始，只不过官方仅仅根据所返回的odoo详细版本号信息就限制了开源社区版的使用，并没有严格检测所谓的企业版商业授权。
标准odoo原生api直连就可以编译app的方式，如果应用在website领域是非常创新有竞争力的，能让很多从odoo8年代开始就建设好的各种存量网站、博客、商城、问卷、活动、课程、自由表单等互联网在线应用，不作任何改动和配置，就可以直接发布出绑定其odoo域名ip的多系统app和多平台小程序，一步跨入移动互联全网通时代。
当然website系列模块很多信息都是以页面html为格式的整体输出结果，并没有规范的json数据接口，这就有必要将常用于服务端的爬虫技术移植到客户端应用，通过对odoo渲染生成的模板页面进行实时结构化数据分析，剥离出各种标准的菜单、页眉、页脚、区块等样式结构和文本、图片、视频、地图、链接等元素内容，就可以输入给各种移动框架的渲染引擎，来动态生成原生的手机app交互界面。
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。
原生H5响应式设计自适配是成本最低的，企业版自带主题开箱即用，社区版使用第三方比如OCA组织的web_responsive模块搭配使用效果也很好。各种应用场景广泛兼容，缺点是PC大屏幕菜单不够直观有些人可能不习惯，以及手机浏览器也要加载并执行完整个odoo富客户端框架才能显示过于笨重，体验一般毕竟只是个Web页面。
官方App套壳封装则是进阶之路，UI主题风格虽然不变，但可以在H5的基础上多出一些原生能力替代，比如多套odoo系统用户切换，日期时间下拉框选择控件、消息提醒等功能体验都有所提升。安卓和苹果系统版本都有，缺点就是还没开源无法基于原生能力部分进行扩展开发。
企业微信、钉钉、飞书、WeLink等移动互联网开放平台的集成，odoo整体可以作为其子系统，也可以将各个功能模块平移成各个子应用。其中组织架构和消息通知的互联互通是核心，更多上层应用的一体化整合需要根据需求和成本来定制。优势是有很多开源的通用性模块可参考借鉴和经验交流，取长补短强强联合，最终的用户体验一定是最佳的，毕竟一个国民APP就可完成所有功能。缺点则是odoo就变成没有存在感的纯后台管理和服务支撑了，当然还有一些封闭式的内网环境也不适合。
第三方用RPC协议对接的产品级APP，比如MERP是综合全能型，还有一种是模块应用级对接。这和官方App配置差不多，服务端协议域名端口用户名密码设置正确就可以用了，但是体验完全不同，因为接口只传输必要的数据，界面则是本地化原生控件动态渲染，整体流畅度比HTML页面好太多。缺点就是商业软件没法定制，以及Web前端界面的一些深度二次开发在这里没法体现。
完全定制开发的项目级APP，可以用成本最高性能最好的Android和iOS各端原生开发，也可以先用当下流行轻量级的Vue、React框架重构整个odoo前端UI层，然后用Hybrid混合模式打包成双端应用，更可以用符合中国国情的uniapp、Taro等多端开发框架统一发布微信百度支付宝头条抖音360QQ等战国时代小程序平台的应用需求。
完美理想终身事业型的史诗级APP，吸收上述所有方案经验和精华，不仅支持odoo所有版本，更支持桌面端、平板端、手机端的主流操作系统全部平台的应用程序、APP、小程序、快应用。完全协议原生渲染，包括初始化应用名称、界面主题以及首页、页眉、页脚、菜单等内容都由odoo动态配置实时下发全网通客户端生成。其最大缺点就是如果没有网络将只有一个空白雪花页，优势则颠覆了传统应用的开发方式，只要用odoo最传统的ERP实施理念即可以免开发的拥有自己独一无二的全平台动态同步APP。。。
TinyERP远古时期，是没有Web版的，也就是用Client客户端的，就如同现在手机App一样是需要每台电脑都安装的，俗称C/S架构模式，一般每次升级版本服务端和客户端都需要同步更新。现在看起来很不方便，但是当年这种采用GTK+XMLRPC的解决方案已经是很优秀了，不仅能跨平台支持，还有完整的协议来动态呈现菜单、执行动作、渲染视图及反馈交互。
OpenERP上个世纪，与时俱进的引入了B/S架构Web版，但还保留Client到最后7.0版本才无奈抛弃，毕竟鱼与熊掌很难兼得：Web端的快速革新始终受限于Client端的兼容性，因为动态协议虽美丽，但协议自身还需要不断迭代加强，这是日新月异Web世界与保守稳定Client王朝之间的结构性矛盾。现在renjie.me看来这次革命很及时，又一次走在历史的正确道路上，否则现在估计会有基于WebKit内核的客户端版本。
Odoo改革开放，在HTML5浏览器统一天下的趋势和潮流下，姓open姓erp已不重要了，综合卓越的、基础扎实的、业务饱满的，版权干净的，且历史包袱和技术债务都不重的，完全可以冲击企业级操作系统的宝座，其轻快的日日发新版本腾飞，生态又由与日俱增的appstore应用市场和开源社区保驾护航，使得各种层次的企业级应用开发者都可以在odoo上找到自己的归属与定位。截止目前其在企业应用操作系统的地位犹如Android+iOS合体遥遥领先：所谓的社区版就如安卓开放的架构并自带原生的应用，任何组织都可以基于这个成熟的开源基础设施来打造自己的企业级甚至行业级业务系统，而官方企业版不就是那个封闭的苹果巨人及其相关付费app吗：）