On Thu, Apr 3, 2008 at 11:17 AM, Michael Papp <[EMAIL PROTECTED]> wrote:
> Dependency injection would also work well, albeit with slightly tighter > coupling to the Shindig code itself. Not to initiate a conversation about > DI pros and cons, but changes to Shindig internals is more likely to > require > one to modify or rewrite one's code with the DI approach then with a pure > SPI offering. Even with an SPI approach, there will still be DI anyway (even if it's only used internally). Very few people will likely have to replace BasicRemoteContentFetcher, for instance (so it doesn't belong in the SPI), but there will be occasional deployments that require something else. DI makes testing easier, and that's why we'll design the code in that way regardless of its other benefits. I'd suspect that the social data pieces are the best fit for an SPI approach. Lastly, the "classNames as servlet init-params in the web.xml file" > approximates the SPI approach, but that requires the project take a more > stringent approach to identifying and isolating "swappable" class units > then > an SPI approach. An SPI is a contract; this approach is basically a > promise. To clarify, interdependencies in the class hierarchy and shared > dependencies must be observed such that swapping certain classes remain > possible as the project moves forward. This is basically spring though. Instead of reinventing it, we should just design the code in a way that allows someone who likes spring to use spring. The RPC approach that is currently being promoted is also a good approach at > providing abstraction and avoiding implementation dependencies. The 'bad' > part of this approach is that you already have all pieces of a Java > implementation that could so easily provide an SPI and hook directly to > the > backend, without the need for implementing a layer of RPC services on top > of > existing backend functionality. This is likely not an issue anyway -- in practice, the pieces that need to be wired together are best dealt with as independent servers in a production environment for scalability. Small sites (less than a million requests per day) can probably get away with this, but sites this small are rarely using Java anyway so it wouldn't matter that much if it was easier to use an spi or implement some interfaces or anything else because they can't use it in either case. -- ~Kevin
