6:57 p.m.
Hello all,
while creating the basic scaffolding for the new GridDialect, I
called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
is rather long, but descriptive.
Q1: any better name?
The current one which we have working on Infinispan "embedded mode"
is named "hibernate-ogm-infinispan".
Q2: do we need to rename the existing one? If not, what to we call it
in our documentation to disambiguate?
Thanks,
Sanne
7:07 p.m.
I would use:
hibernate-ogm-infinispan-hotrod
For Neo4j we have a similart problem
at the moment the directory is hibernate-ogm-neo4j and the short name is
'neo4j_embedded'
Whatever we choose I guess we should be consistent:
I guess haivng
- hibernate-ogm-infinispan/embedded
- hibernate-ogm-infinispan/hotrod
On Mon, Dec 14, 2015 at 5:57 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Hello all,
while creating the basic scaffolding for the new GridDialect, I
called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
is rather long, but descriptive.
Q1: any better name?
The current one which we have working on Infinispan "embedded mode"
is named "hibernate-ogm-infinispan".
Q2: do we need to rename the existing one? If not, what to we call it
in our documentation to disambiguate?
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:09 p.m.
Does it have to be a separate module to begin with?
For MongoDB - which contains two datastore providers (MongoDB, Fongo)
and Redis - which also will have two different dialects as per Mark's
pending PR - it's one module.
We should stick to one pattern, and having one module seems easier on
the user to me. So unless you see a strong advantage for two modules
I'd say let's use one.
Regarding the provider names, "infinispan" and "infinspan-remote"
seem
good. If you think remote will be more common eventually, we may
rename the current one and have "infinispan-embedded" and
"infinispan". Requires a change to existing users, but it seems
acceptable to do in 5.
I would not have "hotrod" in the name, this is a technicality I'd
prefer to not expose at this level. Rather "remote" vs. "embedded"
which will be stable also if specific protocols change.
--Gunnar
2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org>:
Hello all,
while creating the basic scaffolding for the new GridDialect, I
called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
is rather long, but descriptive.
Q1: any better name?
The current one which we have working on Infinispan "embedded mode"
is named "hibernate-ogm-infinispan".
Q2: do we need to rename the existing one? If not, what to we call it
in our documentation to disambiguate?
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:21 p.m.
Sorry for the previous email, I've sent it too soon pressing some strange
keywords combination.
We should stick to one pattern, and having one module seems easier
on
the user to me. So unless you see a strong advantage for two modules
I'd say let's use one.
One general disadvantage I can see is that you add in the classpath
dependencies that you don't need (maybe).
I would not have "hotrod" in the name, this is a
technicality I'd
prefer to not expose at this level. Rather "remote" vs. "embedded"
Are there other backends that could be associated with infinispan? Maybe a
different remote protocol?
Regarding the provider names, "infinispan" and
"infinspan-remote" seem
good. If you think remote will be more common eventually, we may
rename the current one and have "infinispan-embedded" and
"infinispan". Requires a change to existing users, but it seems
acceptable to do in 5.
I think that in general, remote dbs are more common. I would prefer
"infinispan-embedded" and "infinispan".
I guess based on what we decide we should also adapt the names and the
modules for Neo4j to be consistent.
On Mon, Dec 14, 2015 at 6:09 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> Does it have to be a separate module to begin with?
>
> For MongoDB - which contains two datastore providers (MongoDB, Fongo)
> and Redis - which also will have two different dialects as per Mark's
> pending PR - it's one module.
>
We should stick to one pattern, and having one module seems easier
on
the user to me. So unless you see a strong advantage for two modules
I'd say let's use one.
>
Regarding the provider names, "infinispan" and
"infinspan-remote" seem
good. If you think remote will be more common eventually, we may
rename the current one and have "infinispan-embedded" and
"infinispan". Requires a change to existing users, but it seems
acceptable to do in 5.
>
I would not have "hotrod" in the name, this is a
technicality I'd
prefer to not expose at this level. Rather "remote" vs. "embedded"
> which will be stable also if specific protocols change.
>
> --Gunnar
>
>
> 2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org>:
> > Hello all,
> > while creating the basic scaffolding for the new GridDialect, I
> > called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> > is rather long, but descriptive.
> >
> > Q1: any better name?
> >
> >
> > The current one which we have working on Infinispan "embedded
mode"
> > is named "hibernate-ogm-infinispan".
> >
> > Q2: do we need to rename the existing one? If not, what to we call it
> > in our documentation to disambiguate?
> >
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
7:35 p.m.
On 14 December 2015 at 18:09, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Does it have to be a separate module to begin with?
For MongoDB - which contains two datastore providers (MongoDB, Fongo)
and Redis - which also will have two different dialects as per Mark's
pending PR - it's one module.
We should stick to one pattern, and having one module seems easier on
the user to me. So unless you see a strong advantage for two modules
I'd say let's use one.
The two are very different; in terms of end-user concerns the
featuresets are different; for example one is able to integrate with
JTA transactions, the other isn't. One requires Externalizers, the
other requires protobuf schemas, etc.. even the configuration methods
and available options will be totally different to end users.
The dependencies are extremely different too; you might consider these
"an implementation detail", yet the Hot Rod client requires a lot more
stuff which I'd rather not push to users of Infinispan Embedded.
To have Infinispan Embedded users avoid this mess, they'd either need
to depend on a different artefact or to deal with lists of exclusions.
I think having a different artefact is nicer.
So, be it to clarify differences in featuresets. architecture or how
to configure it all, in terms of documentation I think we should
clearly introduce the split right after introducing what Infinispan
is, and there is were I need some proper terminology to be
established.
Regarding the provider names, "infinispan" and "infinspan-remote"
seem
good. If you think remote will be more common eventually, we may
rename the current one and have "infinispan-embedded" and
"infinispan". Requires a change to existing users, but it seems
acceptable to do in 5.
Right but if we already are suspecting that this might change, I'd
rather do it now:
- we're preparing a major release
- will impact more users later (hopefully growing userbase?)
I would not have "hotrod" in the name, this is a
technicality I'd
prefer to not expose at this level. Rather "remote" vs. "embedded"
which will be stable also if specific protocols change.
Good point, I'm ok to go with "Infinispan Remote" if you think that's
easier to new users, but that's inconsistent with the choice of the
Infinispan project; also keep in mind we're coupling this new dialect
to Hot Rod specifically.
Also "Hot Rod" is the brand name of Infinispan remoting technology; if
it evolves, it will evolve the protocol but it's unlikely to change
its name.
Sanne
--Gunnar
2015-12-14 18:57 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org>:
> Hello all,
> while creating the basic scaffolding for the new GridDialect, I
> called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
> is rather long, but descriptive.
>
> Q1: any better name?
>
>
> The current one which we have working on Infinispan "embedded mode"
> is named "hibernate-ogm-infinispan".
>
> Q2: do we need to rename the existing one? If not, what to we call it
> in our documentation to disambiguate?
>
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3056
days inactive
3056
days old
4 comments
4 participants
participants (4)
-
Davide D'Alto -
Davide D'Alto -
Gunnar Morling -
Sanne Grinovero