-
Notifications
You must be signed in to change notification settings - Fork 59
代码重构与化简 #141
Comments
不管目录重整多不多,我们可以先合议一个最终目标出来,后面一步一步改。本意是改的目录结构大家提前有一个共识 (参考 #195 的讨论) 整体项目分为 core 和 dist 两大部分,按照讨论,所有 client/server 相关的模块放在 dist,dist 在 core 之上构建。
|
把rserver和mserver改名成replica_server和meta_server就好,别的没问题。 |
为什么还要保持两个目录(dist,core)呢?为什么不去掉dist,core并把目录平摊到一层呢? |
core 目录下为 dsn.runtime 相关代码, 因为当时许多组件的代码还和 dsn.runtime 绑定, 所以我们在结构上分为 core 和 dist, 分别代表 dsn.runtime 与 基于runtime的上层实现. 而目前许多模块已经从 dsn.runtime 剥离出来, 并且目前距上次讨论已经间隔2年, 确实我们应该再次整理代码的结构.
|
还要有个common吧?存放meta server和replica server共同使用的部分,比如replication_options等 |
可以参考下kudu的目录结构和划分逻辑: |
所以,我们是不是也要把remote command和ddl_client这些也放到tool里,而不是单独放在一个路径下? |
可以多加个 common, 虽然我不太喜欢这个名字,因为很难理解这个 common 指的是什么。
kudu 的 tools 本质上是 command-line tool, 是无法跟 ddl_client 和 remote_command 相提并论。 如果后续将 Pegasus 与 rdsn 合并,或许可以把 remote_command 和 ddl_client 放到 shell 的目录下。
|
另外还有个tools,所以应该是这样的:
|
tools 包括哪些组件? |
比如profiler,tracer这些,具体需要我后面整理一下 |
profiler,tracer 应该属于util |
我理解utils应该是最基础的工具类,应该是即使是跨项目也可以直接用的东西。但是profiler和tracer依赖了很多task和rpc的东西 |
我以为你说的是#510 这个tracer。依赖task,rpc的那个是不是放到common好点? |
如吴涛所说,其实common这个路径看名字很难理解是做什么的。所以我在想要不要common改成common_define,里面只保留一些公共的变量定义等等,不向里面放入太多东西 |
完成
TBD
(serialization: completely remove protobuf support #161, *: remove *.types.h files #164)
The text was updated successfully, but these errors were encountered: