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