重构构建流程并添加新功能
Loyalsoldier opened this issue · comments
随着本项目的成长和影响力的扩大，在过去一年左右的时间里，本项目出现了几个问题：
@cn属性的存在，导致geolocation-!cn类别里出现了很多“大陆域名”（隶属于非大陆企业，但在大陆有接入点的域名）- 每个列表的域名规则无法去重（如
geolocation-!cn包含大量顶级域，可以通过树去重，以减少生成文件的体积）
现在此提议，在构建流程中引入多种选项和特性：
- 自动按优先级查找
data文件夹的位置（命令行选项） - 可自定义生成文件的输出目录（命令行选项）
- 可自定义用哪个列表来生成
gfwlist.txt文件（命令行选项。geolocation-cn或者cn即为白名单，geolocation-!cn即为黑名单） - 可自定义去除带有特定属性的规则（命令行选项）：生成文件时，去除带有某些特定属性的规则，如：
geolocation-!cn列表去除@cn属性的规则；geolocation-cn列表去除@!cn属性的规则（目前并无此规则，但后续可以考虑加入此类域名到geolocation-cn列表） - 扩展
include语法：支持include:filename@attribute（由此，geolocation-cn可以include:google@cn；geolocation-!cn可以include:alibaba@!cn）
- gfwlist 作为一个临时解决方案，不应该继续扩大影响力，这种方案应该逐渐被移除；
- 这会改变集合的定义，如果移除，那为什么不用一个新的诸如 geopop 这样的名字；
- gfwlist 作为一个临时解决方案，不应该继续扩大影响力，这种方案应该逐渐被移除；
- 这会改变集合的定义，如果移除，那为什么不用一个新的诸如 geopop 这样的名字；
第四点没看懂什么意思
比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗
比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗
附议。
我觉得geolocation-cn、geolocation-!cn的变更可以留到另一个issue，保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受，如果以后用户想要自行构建geosite，应该会用上这些功能。
另外想问一个无关的问题，有办法在配置文件中指定DLC中的所有列表吗？例如geosite:all这种特殊值？
比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗
这就涉及到怎么理解 geolocation-!cn 的定义了，你可以理解为公司注册地是海外，也可以理解为域名接入点在海外。对于用户而言，好用才是第一位，意味着按用户直觉，geolocation-!cn 生成的列表就不应该出现接入点在大陆的域名。所以，我觉得引入这个功能是有必要的。
另外，结合这个新的 include 语法：
- 在
cn列表里include:geolocation-!cn@cn - 在
geolocation-!cn列表里include:geolocation-cn@!cn
就可以实现 @cn 和 @!cn 属性规则乾坤大挪移的效果，一切的不合理就回到了直觉该有的模样，而且不需要新增诸如 google-cn 这样奇怪且多余的列表。
另外，geolocation-!cn、geolocation-cn 和 cn 三个生成的列表里，也不需要出现带有 @ads 属性的规则，纯粹浪费空间，可以在生成时一并去除。
如果觉得「在生成列表时去除带有某些属性的规则」的功能违反之前的共识，本项目可以默认不开启这个功能。把功能开启的选择权留给有需要的用户或项目（例如 shadowsocks-windows）
目前在用的有 ss-win 和trojan-go ，都是通过pb引入，所以我觉得从生成器入手可能也不行
目前在用的有 ss-win 和trojan-go ，都是通过pb引入，所以我觉得从生成器入手可能也不行
项目都是读取的 dlc.dat 文件啊，在生成 dlc.dat 文件的阶段就不加入被剔除的规则到 dlc.dat 文件里不就好了吗
如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据，我觉得这会给未来带来很大的麻烦。
这个问题要回到之前 SS 的 ISSUE 上
如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据，我觉得这会给未来带来很大的麻烦。这个问题要回到之前 SS 的 ISSUE 上
有几个选择：
- 我们提供这个功能，默认不开启这个功能
- 实现 1，且再生成一份
geolocation-!cn列表无@cn规则的dlc.dat（说明区别） - 实现 1，且 Shadowsocks 项目组开一个新仓库，基于这里的
data文件夹，定期发布他们自定义构建的dlc.dat。其余想自定义 dlc.dat 的用户或项目，也可以这么操作。
cc @studentmain
Since 4.3.0.0, shadowsocks-windows defaults to direct connection for domains in geosite:cn and geosite:geolocation-!cn@cn in PAC mode.
More details: shadowsocks/shadowsocks-windows#2990
我觉得
geolocation-cn、geolocation-!cn的变更可以留到另一个issue，保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受，如果以后用户想要自行构建geosite，应该会用上这些功能。另外想问一个无关的问题，有办法在配置文件中指定DLC中的所有列表吗？例如
geosite:all这种特殊值？
geosite:all 当然是可以实现的，只是生成的文件会大一倍。其实只要在路由设置里直接设置全部代理或者全部直连，不就相当于 all 了吗？为何需要这个 geosite:all，有什么具体的应用场景吗？
我觉得这边的讨论有些陷入停滞了，目前 #255 还没有人审核过，我觉得现在主要影响进展的问题有两点：
- attr 被视为一个实验性的功能，但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
- 我们不太愿意改变之前对诸如
geolocation-cn这些域名分类的定义
但是总的来说，这些都不妨碍 #255 得到推进，从 PR 的主要因素来说，这个 PR 主要做的就是构建流程的改进，而这些改进在我看来都很实用且必要。
我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR，这样我们可以绕开很早就有且一直难以得到定论的问题，先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的，但我猜想它可能并不是非得和其他改进一同实现不可。同样的，「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。
因为我参与不深，所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进，但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进，加入提取带属性域名的功能，但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目，根据自己的需要改变诸如 cn 文件的内容，来得到自己需要的域名列表。
我觉得这边的讨论有些陷入停滞了，目前 #255 还没有人审核过，我觉得现在主要影响进展的问题有两点：
- attr 被视为一个实验性的功能，但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
- 我们不太愿意改变之前对诸如
geolocation-cn这些域名分类的定义
但是总的来说，这些都不妨碍 #255 得到推进，从 PR 的主要因素来说，这个 PR 主要做的就是构建流程的改进，而这些改进在我看来都很实用且必要。我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR，这样我们可以绕开很早就有且一直难以得到定论的问题，先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的，但我猜想它可能并不是非得和其他改进一同实现不可。同样的，「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。因为我参与不深，所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进，但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进，加入提取带属性域名的功能，但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目，根据自己的需要改变诸如cn文件的内容，来得到自己需要的域名列表。
总体而已，该 PR 的目的是让构建流程扁平化，顺便扩展了 include 的语法，并引入了去除带属性规则的功能。不使用就不打开即可。如果命令行选项不打开，就跟现有的输出没有本质区别，只是规则的顺序不同而已（事实上，目前命令行选项默认没有打开）。
另外，我在自己的 repo 使用了这个 PR 的代码，默认开启了去除属性规则的功能：https://github.com/Loyalsoldier/domain-list-custom
可以看看效果
#259 我也正打算整理DLC， 然后发现你写了支持 include:filename@attr 的代码。
使用 include:filename@attr 并且规范化列表可以解决上述所有问题。
#259 我也正打算整理DLC， 然后发现你写了支持
include:filename@attr的代码。使用
include:filename@attr并且规范化列表可以解决上述所有问题。
其实大部分只有一两个域名的列表是我引入的，当时也没考虑太多。但是现在列表多了之后，反而导致了生成文件的无谓增大；以及 data 目录超过 1000 个条目，无法全部看到。
如果需要纠正这个问题，其实有两个方向：
- 在 data 目录中移除只有一两个域名的列表，并整合到大的分类中
- 在构建阶段，提供一个命令行选项，可以删除「只有给定数量的规则」的列表以减少生成文件的体积
以上两个方案的前提是解决这个问题：v2fly/v2ray-core#237
其实如果不想改变之前对 geolocation 相关列表的「定义、意义和作用」达成的共识，可以新增一个叫 not-cn 的列表，对标 cn 列表，内容为:
include:tld-!cn
include:geolocation-!cn
include:geolocation-cn@!cn
同时，cn 列表修改为:
include:tld-cn
include:geolocation-cn
include:geolocation-!cn@cn
这样就可以绕过 geolocation 这个单词的含义了。只不过又让生成文件臃肿了许多。
至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。
只不过这个方案需要下游和第三方软件也同时支持 v5 的路由系统，才能使用新的 geosite.dat（当然，另一个妥协方案是同时生成展开版的 geosite.dat 和非展开版的 geosite.dat）
无论最终采用哪个方案，#255 里的新构建流程都是可以支持的，因为做到了尽可能的功能解耦。
现在已经陷入了困境，请 @Robot-DaneelOlivaw 也参与下。
抱歉，事务繁忙，没办法及时跟进。
哪怕不更改列表定义，#255 引入的功能也是很实用的，我觉得并没有什么问题，是需要一个人来拍板吗？
至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。
考虑到许多用户在空间紧张的设备上使用，geosite文件能瘦身当然是最好的，不知道性能会不会受到影响？
另外像 v2fly/v2ray-core#237 提到的那样，如果配置文件中有不存在的列表，提示错误后依然能正常启动，那DLC删除/移动列表会少很多束缚。
抱歉，事务繁忙，没办法及时跟进。
哪怕不更改列表定义，#255 引入的功能也是很实用的，我觉得并没有什么问题，是需要一个人来拍板吗？
至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。
考虑到许多用户在空间紧张的设备上使用，geosite文件能瘦身当然是最好的，不知道性能会不会受到影响？
另外像 v2fly/v2ray-core#237 提到的那样，如果配置文件中有不存在的列表，提示错误后依然能正常启动，那DLC删除/移动列表会少很多束缚。
geosite 现在压缩后只有 80~200kb 我觉得问题并不大吧
第二个问题可以解决掉，改成错误但不崩溃（但不清楚是否需要这么做）
的确需要人来拍板，这个项目我并不熟悉，需要你们来决定