On Mon, Dec 22, 2008 at 2:50 PM, Jordan Zimmerman <jord...@shop.com> wrote:
> I've been using Java Shindig for a few weeks now and there are some > things I'd like to see changed. If you'd "like to see things changed", there's only one way it's going to happen: file an issue with specifics of what you'd like to see. If other people agree, they might write even implement it. If they don't, be prepared to write a patch and face the scrutiny of review. > * J2EE vs Plain Java * > The major change should be a refactoring to make Shindig a code library > as opposed to an application. Shindig makes deep assumptions about the > environment it is running in. In particular, it assumes a J2EE compliant > container. It then runs in that container as a standalone application. > Developers must plug in to the Shindig application. I suggest a > refactoring into two libraries: Shindig J2EE and a Shindig Engine. I > don't see why Shindig has to be released as a set of servlets. For > example, ProxyServlet is a thin wrapper around ProxyHandler. So, the > engine is actually already there. Just don't use the war. Use the jars. Ignore the servlet package. If you find there's anything in the servlet package that you think belongs in the core packages, file a ticket with details. > * Dependency Injection is awful * > DI is an implementation detail that should be left to users of Shindig. > Shindig's use of Guice serves to obfuscate the internals of Shindig > without a lot of benefit that I can see. I've been able to get Shindig > up and running without using any of the DI. If I can do that, then it > seems unnecessary. Leave this in the J2EE layer (which should be a > separate library as I said above). If you can get it up and running without using DI, then it sounds like it's not obtrusive at all. We made a conscious and very intentional decision to develop shindig using DI. We're not changing that. If you don't wish to use dependency injection, don't. > * Documentation is not hard to write * > I can't understand why there isn't minimal documentation. Take a few > hours and document the main classes, how they work together and how an > implementer might use them. Further, there are lots of hard coded values > in the JS files (e.g. %js%) that aren't documented anywhere that I can > see. If you see something that isn't well documented enough that you think needs clarification, file a ticket. What do you consider to be the 'main classes' that are lacking documentation? There are certainly some outer edges, like link rewriting, that aren't documented that well, but I'm not seeing any 'main' class that doesn't explain what it's doing and document how methods work. > It's wonderful that Shindig exists. But, so far, it's been very > frustrating trying to get it to work in my environment. My comments > above are a few of the reasons why it's so frustrating. That's why this mailing list exists. We're not going to change our fundamental design objectives to work with your particular environment, though. Shindig's existing design philosophy is heavily influenced by the environments of the people who are writing and contributing code. If you want to influence that design yourself, you'll need to write and contribute code. The burden is on you to prove to us that a particular idea is a good one, and the best way to do that is to get involved. There are basically two types of people who work on open source projects: - People who are paid to do it. They care about their employer's objectives, not yours. - People who have volunteered to work on it. They have many reasons for doing so (learning, consulting gigs, boredom, etc.), and they tend to be short on time. For the most part, they focus on things that a lot of people are asking for, or to scratch a personal itch. Neither of these people are going to pay much attention to some random person sending them a list of feature requirements.
