场景如下：
- 有一些有图形交互界面的行业程序，用户给它提供输入，最终这个软件会产生一个私有格式的文字式的文件，经常带些朴素的表格之类的，以供在相关的场合里使用
- 这个行业呢，有几个大一点的玩家，和一堆小一点的玩家。各家都是传统的玩家心态，想守住自己的一亩地三分田。尽管在同样的行业里，大家多多少少用些不同的用词，流程，规范... 尽管说的都是同一回事。反映在软件里，就是对于同样的信息，产生完全不兼容的文件。各个玩家之间，也故意的相互不交流。甚至于，有时玩家给出文件的时候，是打印成PDF 格式的，而且这个PDF 的内部是混淆过的。
- 在平常使用时，用户需要打开一个桌面程序，输入密码，进入界面，手工敲入文字，选取选择框...等，这个程序的界面是会随着用户的交互而有所变化的，比如，选一个选项A，程序会显示一组后续选项，但如果选了选项B，程序就会显示另外一组后续选项。抽象的描述来说，这个界面是动态的；但是是可重现，可预测的。
- 有些用户呢，有时候需要和多个行业玩家交互，这时候，用户就需要把一个玩家发来的东西，手工提交到另一个玩家的系统里，在和第二个玩家交互之后，有可能还需要把新的内容再提交回给第一个玩家。抽象的来说，对于一个语意信息，用户需要费心费力的挪来挪去，和转变它的表达方式。
. 现在，行业扰动者来了。想在用户端，打通所有行业玩家间的壁垒。也就是说，玩家A发来的一个文件，内容是“选项A，选项B，文字C…”，在保持语意的条件下，转换成玩家B的“选项B‘，文字C’，选项A‘...”。因为时间就是金钱嘛，用户们会为这种服务付费。如果一次转换咱们收个一百万人币，一天一千次转换，那就完成了一个亿的小目标了。
. 这个壁垒连通器呢，想把它放在一个服务器端，对用户按使用量计费。给我一个玩家A形式的文件，我返回一个玩家B形式的文件。
. 抽象上来说，只要定义一套完备的转换规则，这个软件就成了。哪怕咱们用上最菜的码龙，最乱糟糟的测试，无设计的群豺式的敏捷开发战术，997的工作时间... 也能在几个月内砸出一个粗糙的钻石。
. 现在呢，设计的焦点就是，如何在服务器端，完成这个转换？成本什么的现在就先不考虑了，咱们只要一个可行的方案。
--
FROM 47.144.174.*

招呼啥 何必见外
自家的房产，开门进去 端起来就喝 拿起来就吃 进所里就拉 躺倒了就睡了 ...

【 在 cjon 的大作中提到: 】
: 五菱版好多版友在念叨你呢，不打算去打个招呼？
--
FROM 47.144.174.*

有道理...
所以，比如说我有一台16梳的机器，分成7个2核的虚拟机，同时运行它们
主机收到请求，分发给虚拟机
每个虚拟机都有自己的虚拟屏幕，哪怕在主机里把窗口最小化，里面的GUI 程序也不爱影响？
这样 我一台服务器，就可以并发应付7 个请求了

【 在 hgoldfish 的大作中提到: 】
: 远程服务器也可以运行图形界面的啊。还可以运行多个虚拟机。
:
--
FROM 47.144.174.*

比如，你请3个人，6个月搞定，... 已经过了3 个月的试用期了，这3 个人就成了永久员工？

找咨询公司帮忙.... 费用更高些； 而且 我印象中 咨询公司经常是不懂装懂，做的东西 大架子上 中看不中用 华而不实不堪大用啊

关键是 方向错了 努力也白费
所以 想听听诸位大神的意见

【 在 tgfbeta 的大作中提到: 】
: 你自己不是已经表示经过996可以几个月搞定么？
: 那还问个啥劲儿？给码农提需求呗
--
FROM 47.144.174.*

tsla 的自动驾驶出了那么多事 也没经济或法律上的问题的 签合约的时候 加一条免责声明 就差不多了 要求使用者对内容全责负责

【 在 JulyClyde 的大作中提到: 】
: 哈哈哈哈，问到核心要点了
--
FROM 47.144.174.*