Thanks for the reply, Kevin. I am obviously promoting an Java-style SPI approach, and wanted to gauge the interest in the group for such an implementation. To be more forthcoming, I am assisting one (possibly more) nascent ventures in setting up OpenSocial functionality, primarily using the data aspects and little, if any, gadget rendering/hosting features. So it is a natural to abstract parts of the java/social/* classes and build an SPI / drop-in jar architecture for me. I would be happy to contribute this back to the project if there is sufficient interest on the part of other developers. Anyway, just putting my 2 cents on the table.
-Michael > > ---------- Forwarded message ---------- > From: "Kevin Brown" <[EMAIL PROTECTED]> > To: [email protected] > Date: Thu, 3 Apr 2008 11:41:23 -0700 > Subject: Re: Working on data integration guide for Shindig > 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 > > > -
