solrj was not released in 1.2, so the change is not incompatible...
The rationalle for abstract class vs interface is more to do with
usage and future maintenance. If SolrServer is an interface and solr
1.4 adds methods, there is no way to make it backwards compatible --
as an abstract class, we can add a reasonable default behavior.
Since SolrServer is a rather involved action, it seems like it will
tend to be a standalone class. Interfaces are great for OO clarity,
but very difficult to maintain.
Is there a good usage case we are not thinking of before this gets
baked into 1.3?
ryan
On Jun 7, 2008, at 2:13 PM, Alexander Ramos Jardim wrote:
Hello,
Shouldn't SolrServer be an interface that externalizes the
signatures for
classes like CommonsHttpSolrServer, like it was in solr-1.2? Why did
it
became an abstract class?
I can't see any benefit from it, as now I need to type the object as
CommonsHttpSolrServer directly.
I think it is really bad.
--
Alexander Ramos Jardim
