On Wed, Dec 3, 2008 at 6:31 PM, Adam Winer <[EMAIL PROTECTED]> wrote: > On Wed, Dec 3, 2008 at 5:27 PM, Henning P. Schmiedehausen > <[EMAIL PROTECTED]> wrote: >> Adam Winer <[EMAIL PROTECTED]> writes: >> >>>OK, but can you defend SHINDIG-759 as you just filed? Once the >>>XStream code has been fixed, why should @ImplementedBy be removed? >>>How does this patch make things better? IMO, it makes things *far* >>>worse. Either a developer uses this new DefaultGuiceModule and >>>DefaultOpenSocialObjectsModule or you don't. If the developer does, >>>their life is unchanged. If the developer doesn't, their code breaks >>>every time we add a new entry to one of these modules, which means >>>their life is worse. >> >> It seems that you believe, that every shindig release (there is no >> release yet, right?) must be drop-in compatible to the previous one. > > As much as is sensible. That's critically important, otherwise your > users stop upgrading. This has been true on every library I've ever > worked on. > >> I very much support your suggestion to pull out all bindings that are >> related to setting up a sample server into its own package. > > Agreed, if they're purely sample code that should not be used in production. > >> IMHO there >> should be no Guice Module in gadgets, common and social-api. > > That doesn't follow. It's flat out wrong.
Libraries usually don't have configuration files. And if they do, then it is a single thing that is easy for users to adapt, not spread out into lots of different places. E.g. an explicit configuration object that you pass in or some piece of XML or whatever. As somebody else said, treat the guice wiring as a configuration file. Just because it is Java doesn't make it any less configuration. The two most important rules of configuration IMHO are: * provide sane defaults - stuff that 99% of users will configure in the same way, should be a default that users don't even have to configure unless they need a different value * make it trivially easy to configure - this applies to both "how to configure" (which is what this discussion is about) and "what can be configured" (which is more of a documentation thing) and you need to do both, not only one of them. my 2c, Tom
