[
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178103#comment-17178103
]
Noble Paul edited comment on SOLR-14680 at 8/14/20, 11:52 PM:
--------------------------------------------------------------
{quote}The main reason is that there's nothing in Solr that uses them{quote}
So, you build everything together and and commit everything altogether?
This is how I wish to go about this
* Build the APIs, we should keep it to just the interfaces so that people get
to comment on what it is
* We should build one implementation of these interfaces
* We should slowly refactor our code to use these APIs
{quote}he potential refactoring to use them on that branch would be either
pointless, because of back-compat requirements, {quote}
Can you point out a single reason why using an internal API would result in
backward incompatibility?
This will make Zero changes to any public API that we have today. This will be
a new set of APIs. So, all the users of the old APIs can continue to use those.
All external plugins etc written using that will work exactly as they used to.
We cannot and should not switch over to a new set of interfaces in one major
version. The steps should be as follows
# Create a new set of interfaces in 8x
# We start refacatoring our internal code to use these interfaces
# Once we are reasonably happy about the APIs, we deprecate the existing APIs
# The old APIs will continue to be supported till another major version
There is not point in introducing fresh new APIs in 9.0. We need these
interfaces to be baked in
was (Author: noble.paul):
{quote}The main reason is that there's nothing in Solr that uses them{quote}
So, you build everything together and and commit everything altogether?
This is how I wish to go about this
* Build the APIs, we should keep it to just the interfaces so that people get
to comment on what it is
* We should build one implementation of these interfaces
* We should slowly refactor our code to use these APIs
*
{quote}he potential refactoring to use them on that branch would be either
pointless, because of back-compat requirements, {quote}
Can you point out a single reason why using an internal API would result in
backward incompatibility?
This will make Zero changes to any public API that we have today. This will be
a new set of APIs. So, all the users of the old APIs can continue to use those.
All external plugins etc written using that will work exactly as they used to.
We cannot and should not switch over to a new set of interfaces in one major
version. The steps should be as follows
# Create a new set of interfaces in 8x
# We start refacatoring our internal code to use these interfaces
# Once we are reasonably happy about the APIs, we deprecate the existing APIs
# The old APIs will continue to be supported till another major version
There is not point in introducing fresh new APIs in 9.0. We need these
interfaces to be baked in
> Provide simple interfaces to our concrete SolrCloud classes
> -----------------------------------------------------------
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Minor
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is
> extremely difficult.
> SOLR-14613 is attempting to create such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these
> interfaces. We will start out with a subset of required interfaces. We
> guarantee is that signatures of methods in these interfaces will not be
> deleted/changed . But we may add more methods as and when it suits us
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
