Hehehe, no probs! You've got a point there :) Now, stop hijacking my threads!! ;) Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/ -----Original Message----- From: Brian Stansberry Sent: 27 November 2006 18:03 To: Galder Zamarreno; Manik Surtani; genman(a)noderunner.net Cc: jbosscache-dev(a)lists.jboss.org Subject: RE: [jbosscache-dev] JBCACHE-867 jbosscache-dev-bounces(a)lists.jboss.org wrote: (Galder, my apologies in advance for deliberately misinterpreting your post; the above phrasing gave me a chance to say something that's been bugging me for a while...) I hope we can not have any concept of "available space" in the API. The API should expose what it needs to expose for users to have the intended functionality as cleanly as possible. If that means an interface has 100 methods, so be it. A really large interface may be a sign that refactoring needs to be done or the intended functionality is too broad or whatever, but if in the end the methods are required to do the job, then they should go in and should be located where they make the most sense. The problem with the old TreeCache API wasn't so much the number of methods as it was the fact that 1) there was no public Interface separate from the internal-use-only public methods and 2) cache configuration wasn't cleanly separated from cache operation. OK, that's off my chest; climbing down from soapbox now... ;)