Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

重构构建流程并添加新功能 #256

Open
Loyalsoldier opened this issue Oct 18, 2020 · 26 comments
Open

重构构建流程并添加新功能 #256

Loyalsoldier opened this issue Oct 18, 2020 · 26 comments

Comments

@Loyalsoldier
Copy link
Collaborator

Loyalsoldier commented Oct 18, 2020

随着本项目的成长和影响力的扩大,在过去一年左右的时间里,本项目出现了几个问题:

  • @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@cngeolocation-!cn 可以 include:alibaba@!cn

⚠️ 注意:规则去重功能只处理不带属性的 Domain 类型的规则。

@kslr
Copy link
Contributor

kslr commented Oct 19, 2020

  1. gfwlist 作为一个临时解决方案,不应该继续扩大影响力,这种方案应该逐渐被移除;
  2. 这会改变集合的定义,如果移除,那为什么不用一个新的诸如 geopop 这样的名字;

@Loyalsoldier
Copy link
Collaborator Author

  1. gfwlist 作为一个临时解决方案,不应该继续扩大影响力,这种方案应该逐渐被移除;
  2. 这会改变集合的定义,如果移除,那为什么不用一个新的诸如 geopop 这样的名字;

第四点没看懂什么意思

@kslr
Copy link
Contributor

kslr commented Oct 19, 2020

比如 geolocation-cn 就是一个集合的定义,如果允许修剪类型不就破坏掉这个概念了吗

@IceCodeNew
Copy link
Collaborator

比如 geolocation-cn 就是一个集合的定义,如果允许修剪类型不就破坏掉这个概念了吗

附议。

@Robot-DaneelOlivaw
Copy link
Contributor

Robot-DaneelOlivaw commented Oct 19, 2020

我觉得geolocation-cngeolocation-!cn的变更可以留到另一个issue,保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受,如果以后用户想要自行构建geosite,应该会用上这些功能。

另外想问一个无关的问题,有办法在配置文件中指定DLC中的所有列表吗?例如geosite:all这种特殊值?

@Loyalsoldier
Copy link
Collaborator Author

Loyalsoldier commented Oct 19, 2020

比如 geolocation-cn 就是一个集合的定义,如果允许修剪类型不就破坏掉这个概念了吗

这就涉及到怎么理解 geolocation-!cn 的定义了,你可以理解为公司注册地是海外,也可以理解为域名接入点在海外。对于用户而言,好用才是第一位,意味着按用户直觉,geolocation-!cn 生成的列表就不应该出现接入点在大陆的域名。所以,我觉得引入这个功能是有必要的。

另外,结合这个新的 include 语法:

  • cn 列表里 include:geolocation-!cn@cn
  • geolocation-!cn 列表里 include:geolocation-cn@!cn

就可以实现 @cn@!cn 属性规则乾坤大挪移的效果,一切的不合理就回到了直觉该有的模样,而且不需要新增诸如 google-cn 这样奇怪且多余的列表。

另外,geolocation-!cngeolocation-cncn 三个生成的列表里,也不需要出现带有 @ads 属性的规则,纯粹浪费空间,可以在生成时一并去除。

@kslr
Copy link
Contributor

kslr commented Oct 19, 2020

关于第一点,可以回到这个问题 #28

@Loyalsoldier
Copy link
Collaborator Author

如果觉得「在生成列表时去除带有某些属性的规则」的功能违反之前的共识,本项目可以默认不开启这个功能。把功能开启的选择权留给有需要的用户或项目(例如 shadowsocks-windows)

@kslr
Copy link
Contributor

kslr commented Oct 20, 2020

目前在用的有 ss-win 和trojan-go ,都是通过pb引入,所以我觉得从生成器入手可能也不行

@Loyalsoldier
Copy link
Collaborator Author

目前在用的有 ss-win 和trojan-go ,都是通过pb引入,所以我觉得从生成器入手可能也不行

项目都是读取的 dlc.dat 文件啊,在生成 dlc.dat 文件的阶段就不加入被剔除的规则到 dlc.dat 文件里不就好了吗

@kslr
Copy link
Contributor

kslr commented Oct 20, 2020

如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据,我觉得这会给未来带来很大的麻烦。

这个问题要回到之前 SS 的 ISSUE 上

@Loyalsoldier
Copy link
Collaborator Author

Loyalsoldier commented Oct 20, 2020

如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据,我觉得这会给未来带来很大的麻烦。

这个问题要回到之前 SS 的 ISSUE 上

有几个选择:

  1. 我们提供这个功能,默认不开启这个功能
  2. 实现 1,且再生成一份 geolocation-!cn 列表无 @cn 规则的 dlc.dat(说明区别)
  3. 实现 1,且 Shadowsocks 项目组开一个新仓库,基于这里的 data 文件夹,定期发布他们自定义构建的 dlc.dat。其余想自定义 dlc.dat 的用户或项目,也可以这么操作。

@kslr
Copy link
Contributor

kslr commented Oct 20, 2020

cc @studentmain

@database64128
Copy link
Contributor

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

@Loyalsoldier
Copy link
Collaborator Author

我觉得geolocation-cngeolocation-!cn的变更可以留到另一个issue,保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受,如果以后用户想要自行构建geosite,应该会用上这些功能。

另外想问一个无关的问题,有办法在配置文件中指定DLC中的所有列表吗?例如geosite:all这种特殊值?

geosite:all 当然是可以实现的,只是生成的文件会大一倍。其实只要在路由设置里直接设置全部代理或者全部直连,不就相当于 all 了吗?为何需要这个 geosite:all,有什么具体的应用场景吗?

@IceCodeNew
Copy link
Collaborator

我觉得这边的讨论有些陷入停滞了,目前 #255 还没有人审核过,我觉得现在主要影响进展的问题有两点:

  1. attr 被视为一个实验性的功能,但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
  2. 我们不太愿意改变之前对诸如 geolocation-cn 这些域名分类的定义
    但是总的来说,这些都不妨碍 Refactor the build process & add some features #255 得到推进,从 PR 的主要因素来说,这个 PR 主要做的就是构建流程的改进,而这些改进在我看来都很实用且必要。

我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR,这样我们可以绕开很早就有且一直难以得到定论的问题,先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的,但我猜想它可能并不是非得和其他改进一同实现不可。同样的,「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。

因为我参与不深,所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进,但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进,加入提取带属性域名的功能,但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目,根据自己的需要改变诸如 cn 文件的内容,来得到自己需要的域名列表。

@Loyalsoldier
Copy link
Collaborator Author

我觉得这边的讨论有些陷入停滞了,目前 #255 还没有人审核过,我觉得现在主要影响进展的问题有两点:

  1. attr 被视为一个实验性的功能,但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
  2. 我们不太愿意改变之前对诸如 geolocation-cn 这些域名分类的定义
    但是总的来说,这些都不妨碍 Refactor the build process & add some features #255 得到推进,从 PR 的主要因素来说,这个 PR 主要做的就是构建流程的改进,而这些改进在我看来都很实用且必要。

我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR,这样我们可以绕开很早就有且一直难以得到定论的问题,先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的,但我猜想它可能并不是非得和其他改进一同实现不可。同样的,「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。

因为我参与不深,所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进,但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进,加入提取带属性域名的功能,但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目,根据自己的需要改变诸如 cn 文件的内容,来得到自己需要的域名列表。

总体而已,该 PR 的目的是让构建流程扁平化,顺便扩展了 include 的语法,并引入了去除带属性规则的功能。不使用就不打开即可。如果命令行选项不打开,就跟现有的输出没有本质区别,只是规则的顺序不同而已(事实上,目前命令行选项默认没有打开)。

@Loyalsoldier
Copy link
Collaborator Author

另外,我在自己的 repo 使用了这个 PR 的代码,默认开启了去除属性规则的功能:https://github.com/Loyalsoldier/domain-list-custom

可以看看效果

@akiirui
Copy link
Contributor

akiirui commented Oct 28, 2020

#259 我也正打算整理DLC, 然后发现你写了支持 include:filename@attr 的代码。

使用 include:filename@attr 并且规范化列表可以解决上述所有问题。

@Loyalsoldier
Copy link
Collaborator Author

Loyalsoldier commented Oct 31, 2020

#259 我也正打算整理DLC, 然后发现你写了支持 include:filename@attr 的代码。

使用 include:filename@attr 并且规范化列表可以解决上述所有问题。

其实大部分只有一两个域名的列表是我引入的,当时也没考虑太多。但是现在列表多了之后,反而导致了生成文件的无谓增大;以及 data 目录超过 1000 个条目,无法全部看到。

如果需要纠正这个问题,其实有两个方向:

  • 在 data 目录中移除只有一两个域名的列表,并整合到大的分类中
  • 在构建阶段,提供一个命令行选项,可以删除「只有给定数量的规则」的列表以减少生成文件的体积

以上两个方案的前提是解决这个问题:v2fly/v2ray-core#237

@Loyalsoldier
Copy link
Collaborator Author

Loyalsoldier commented Oct 31, 2020

其实如果不想改变之前对 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 这个单词的含义了。只不过又让生成文件臃肿了许多。

@Loyalsoldier
Copy link
Collaborator Author

Loyalsoldier commented Oct 31, 2020

至于解决生成文件臃肿的问题,有一个方案:趁着 V2Ray 准备发 v5 版的东风,改造 v2ray 的路由系统,以便支持 geosite.dat 内的列表内嵌结构。意为,不需要把每个列表都拍平(不需要展开 include 的规则),直接 include 即可,而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

只不过这个方案需要下游和第三方软件也同时支持 v5 的路由系统,才能使用新的 geosite.dat(当然,另一个妥协方案是同时生成展开版的 geosite.dat 和非展开版的 geosite.dat)

@Loyalsoldier
Copy link
Collaborator Author

无论最终采用哪个方案,#255 里的新构建流程都是可以支持的,因为做到了尽可能的功能解耦。

@kslr
Copy link
Contributor

kslr commented Nov 21, 2020

现在已经陷入了困境,请 @Robot-DaneelOlivaw 也参与下。

@Robot-DaneelOlivaw
Copy link
Contributor

抱歉,事务繁忙,没办法及时跟进。

哪怕不更改列表定义,#255 引入的功能也是很实用的,我觉得并没有什么问题,是需要一个人来拍板吗?

至于解决生成文件臃肿的问题,有一个方案:趁着 V2Ray 准备发 v5 版的东风,改造 v2ray 的路由系统,以便支持 geosite.dat 内的列表内嵌结构。意为,不需要把每个列表都拍平(不需要展开 include 的规则),直接 include 即可,而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

考虑到许多用户在空间紧张的设备上使用,geosite文件能瘦身当然是最好的,不知道性能会不会受到影响?

另外像 v2fly/v2ray-core#237 提到的那样,如果配置文件中有不存在的列表,提示错误后依然能正常启动,那DLC删除/移动列表会少很多束缚。

@kslr
Copy link
Contributor

kslr commented Nov 22, 2020

抱歉,事务繁忙,没办法及时跟进。

哪怕不更改列表定义,#255 引入的功能也是很实用的,我觉得并没有什么问题,是需要一个人来拍板吗?

至于解决生成文件臃肿的问题,有一个方案:趁着 V2Ray 准备发 v5 版的东风,改造 v2ray 的路由系统,以便支持 geosite.dat 内的列表内嵌结构。意为,不需要把每个列表都拍平(不需要展开 include 的规则),直接 include 即可,而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

考虑到许多用户在空间紧张的设备上使用,geosite文件能瘦身当然是最好的,不知道性能会不会受到影响?

另外像 v2fly/v2ray-core#237 提到的那样,如果配置文件中有不存在的列表,提示错误后依然能正常启动,那DLC删除/移动列表会少很多束缚。

geosite 现在压缩后只有 80~200kb 我觉得问题并不大吧
第二个问题可以解决掉,改成错误但不崩溃(但不清楚是否需要这么做)

的确需要人来拍板,这个项目我并不熟悉,需要你们来决定

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants