Igniters, Seems that within Ignite-3 we have some mess in terms like manager, cpu, service, module, etc. Let's clarify this point. Also It'll be great to discuss the rules of dividing code into modules. I'll use the context of Ignite cluster & node lifecycle <https://github.com/apache/ignite-3/blob/ignite-14393/modules/runner/README.md> for terms definition and as an example source.
*Terms clarification.* - Component - semantically consistent part of Ignite that in most cases will have component-public but ignite-internal API and a lifecycle, somehow related to the lifecycle of a node or cluster. So, *structurally* TableManager, SchemaManager, AffinityManager, etc are all components. For example, TableManager will have methods like createTable(), alterTable(), dropTable(), etc and a lifecycle that will create listeners (aka DistributedMetastorage watches) on schema and affinity updates in order to create/drop raft servers for particular partitions that should be hosted on local node). Components are lined up in a graph without cycles, for more details please see mentioned above Ignite cluster & node lifecycle. <https://github.com/apache/ignite-3/blob/ignite-14393/modules/runner/README.md> - Manager is a driving point of a component with high level lifecycle logic and API methods. My intention here is to agree about naming: should we use the term Manager, Processor or anything else? - Service is an entry point to some component/server or a group of components/servers. See RaftGroupService.java <https://github.com/apache/ignite-3/blob/main/modules/raft-client/src/main/java/org/apache/ignite/raft/client/service/RaftGroupService.java> as an example. - Server, for example RaftServer, seems to be self-explanatory itself. *Dividing code into modules.* It seems useful to introduce a restriction that a module should contain at most one component. So that, combining component-specific modules and ones of api, lang, etc we will end up with something like following: - affinity // TO be created. - api [public] - baseline // TO be created. - bytecode - cli - cli-common - configuration - configuration-annotation-processor - core // Module with classes like IgniteUuid. Should we raname it to lang/utils/commons? - metastorage-client // To be created. - metastorage-common // To be created. - metastorage-server // TO be created. - network - raft // raft-server? - raft-client - rest - runner - schema - table // Seems that there might be a conflict between the meaning of table module that we already have and table module with create/dropTable() - vault Also it's not quite clear to me how we should split lang and util classes some of which belong to the public api, and some to the private. Please share your thoughts about topics mentioned above. Best regards, Alexander
