ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Terms clarification and modules splitting logic
Date Wed, 31 Mar 2021 11:27:03 GMT
Alexey,

I would instead  suggest moving the public utility classes to
org.apache.ignite.api. package in the util module to separate them from
internal classes, if we really need this.

Actually, I don't think there is a point in separating public/internal
classes in the util module. What are the benefits of this ?

ср, 31 мар. 2021 г. в 12:16, Alexey Goncharuk <alexey.goncharuk@gmail.com>:

> Alexei,
>
> I had the same opinion regarding the internal package, but we still need to
> somehow distinguish between public and internal classes in the ignite-util
> module. If we introduce the internal package in the util, we should follow
> the same structure in other modules.
>
> Thoughts?
>
> вт, 30 мар. 2021 г. в 18:37, Alexei Scherbakov <
> alexey.scherbakoff@gmail.com
> >:
>
> > +1 to package and module naming.
> > +1 to service definition as "component providing a high-level API to
> > user/other components/services"
> >
> > I would avoid defining strict rules for Manager and Processor.
> > For me it just adds confusion without real value.
> > A component can be a Manager if it manages something, a Processor if it
> > processes something, and so on.
> > I think having Component and Service (which is also a Component) is
> enough.
> > Any component can be singleton or not - it's defined by its lifecycle.
> >
> > +1 to renaming core to something more meaningful, but the name lang
> doesn't
> > fit for a collection of utility classes for me, I would prefer
> ignite-util.
> > Apache Tomcat has the same jar, for reference. I'm also fine to leave it
> as
> > is.
> > -1 to have an "internal" package. All modules are known to be internal
> > except api and (partially) util, so why bother at all?
> >
> >
> > вт, 30 мар. 2021 г. в 12:05, Andrey Mashenkov <
> andrey.mashenkov@gmail.com
> > >:
> >
> > > Agree with package and module naming.
> > >
> > > I just thought that
> > > Service is a self-suffucient component and provides high-level API to
> > > user/other components/services (e.g. RaftService to TableService).
> > > Manager is internal component - a logical brick of the Service (e.g.
> > > RaftGroupManager or TableSchemaManager, TableAffinityManager), it is
> not
> > > self-sufficient as affinity or schema make no sense without the table.
> > > Processor is just helper-component of the Service that routes messages,
> > > executes async tasks, manages subscriptions and implements some
> secondary
> > > functions.
> > >
> > > On Tue, Mar 30, 2021 at 11:24 AM Alexey Goncharuk <
> > > alexey.goncharuk@gmail.com> wrote:
> > >
> > > > 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 <lapin1702@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
> > > > >
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>


-- 

Best regards,
Alexei Scherbakov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message