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.

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

On 24 Mar 2010, at 10:29, Mircea Markus wrote: > > 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. The thought of hacking Maven assemblies any more than I'd need to gives me the jitters! :)

>> >> 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 > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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