On 23 Mar 2010, at 14:33, Manik Surtani wrote:
Mircea and I were chatting about the HotRod client that he is
writing, and we agreed that the best approach as far as API is concerned is for
RemoteCache to extend Cache, RemoteCacheManager to extend CacheManager, etc., to maintain
familiarity with p2p-style interaction with Infinispan as well as some ease in switching
between interaction styles.
One impact of this is that the HotRod client would then have a dependency on
infinispan-core. So the question is, is this OK? Pulling in a large number of classes
that won't really be used except for the super-interfaces?
One alternative is to pull the public API interfaces out of infinispan-core into a very
light infinispan-api module. This way the HotRod client can just add a dependency on this
jar, but it would mean infinispan-core has a dependency on this jar as well. One
side-effect benefit here is that public API will be very clearly defined.
another
would be to include only the classes that are needed by the hot rod client in the hotrod
client distribution.
Thinking some more on the core-api and core-impl spli, one would have to have both of them
at all time in the classpath, which means that autocompletion tools in IDEs for e.g. would
still pick classes from core-impl. Guess the best approach for this is to use OSGI (ifrc
we have a jiea for this).
The advantage I see in having the core-api and core-impl split is for hot rod client not
to take with it more than needed. But that might be solvable through a mvn assembly.
Thoughts?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev