Hello Alexander, Igniters, I support the suggestion, we need to work out some ground rules to have a consistent naming convention. Agree with having at most one component per project module - this requirement may turn out to be too strict in the future, but now it seems reasonable and may help us to better structure the code. Additionally, I would encourage us to make package names consistent with the module's structure to make modules Jigsaw-compliant. We do not have module definitions now, but I think it would be great to have them, it should help us to enforce component boundaries and proper responsibility encapsulation.
As for the naming, it's not entirely clear for me when to use the term Service vs Manager. Serice is an entry point to a component/server, but so is Manager - a Manager defines an API that is exposed by a module to other modules. Subjectively, I see the following difference between a Manager and a Service in the examples of entities you provided: * A Manager is a node singleton. Its whole purpose is to provide an API gateway for other components into a particular subsystem of a node * A Service is an object that is bound to a particular runtime entity (raft group service is bound to a raft group, and we can have multiple Raft groups; partition service is bound to a particular partition). We can re-create services based on changing runtime state and/or configuration. Does this make sense? Finally, I would use lang module name instead of core (the core is confusing because right now core contains all necessary classes required to start a minimal Ignite instance; this sets up wrong expectations for Ignite 3). Additionally, I think it would be good to exploit the old org.apache.ignite and org.apache.ignite.internal naming scheme: all public classes must go to the non-internal package. The ignite-lang module will have both public and internal packages. This automatically implies that all modules except ignite-api and ignite-lang must reside solely in org.apache.ignite.internal.* packages. This will be easy to check and maintain. Throughts? --AG пт, 26 мар. 2021 г. в 20:28, Alexander Lapin <lapin1...@gmail.com>: > 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 >
