This thread has surfaced a number of interesting issues and questions. First, I know the challenges that Tim, Jordan, myself, and others had in picking up and trying to use Shindig. Some of this might be documentation (bits and pieces, spread out all on various blogs, wikis, web sites), but I think Tim's identified a more important and subtle point regarding the intent of Shindig. This is likely because of the excitement, ramp up, and need to deliver function. This is the natural side effect of some very good effort and rapid evolution from which we are all reaping the benefits. Eclipse went through something similar as that project matured. Several things were a result including their API guidelines and a refactoring of the Eclipse download site ( http://www.eclipse.org/downloads/). Maybe we could think about how Shindig is going to be used and structure our APIs and deliverables in this manner. For example, Jordan's "Mediated OpenSocial" came out of a need to have a bare bones set of libraries with a limited set of dependencies, et. Are there similar things that we've learned as the teams from hi5, Plaxo and others have put shindig in production that would help. (BTW, the new web site is a huge step forward. Hats off to the folks that did that effort!!)
Second might be Shindig's dependencies. If you put on "newbie" shoes for a moment, in order to start *really* working with Shindig, you need to know OpenSocial--at a minimum, both gadgets and social APIs, not to mention pipelining, templates, et--Java and/or PHP, Javascript, OAuth, Maven, Guice, and JSON. A related issue with a larger number of dependencies is the added complexity of the various IP licenses that govern their use. I know, I know. This is everyone's favorite issue. Believe me, I've had more "fun" than I'd like with this already, and as a result know lots of good lawyer jokes. (Why don't sharks eat lawyers? Professional courtesy.) This is easy if everything is contained/derived from Apache. But as third party libraries are brought in, it increases the burden to ensure clean IP. Third, we should think about how we balance the current pace of contributions (a good thing) with the ability for adopters to consume these changes (another good thing). As the number of deliverables built on top of Shindig increases, the ability to keep up with the changes decreases. In this case, predictability is a good thing. From a planning perspective, it helps to know that the last Friday in June is when Eclipse will be released, what bugs will be included, new features available, etc. Stable drivers along the way are also a plus. If we stabilize 1.0 now (OpenSocial 0.8.1), when is 1.1 and will this be OpenSocial 0.9? Is Shindig 2.0 the implementation of OpenSocial 1.0? We many not have all the answers, but we should have some kind of roadmap (and returning to the earlier point, we should clearly articulate the expected API compatibility/changes). As we go forward, is it worth stepping back and taking an objective look at what we really want to accomplish with Shindig and how we might be able think about some of these issues? It seems we have evolved quickly and "1.0" may be an opportunity for us to provide some clarity regarding the stability and purpose of the APIs, the extension model, and intent of the code (e.g. framework vs. application). -Mark W. From: "Fisher, Tim" <[email protected]> To: <[email protected]> Date: 04/23/2009 04:39 PM Subject: RE: Shindig API guidelines.... I agree with Jordan that to the new user, its not at all clear what Shindig is and how it works, even after having poured through most of the documentation available for it. I got it down pretty good now, but it took me awhile. As Jordan says there is an initial confusion as to is this a library or an app. Then there is the confusion of is Shindig meant to run alone as a server which your social site is meant to make remote calls to? Or is Shindig meant to be integrated into a social site at the source code level? These things are not clear to new users. There needs to be some type of high level architecture diagrams and overview available I think. Tim The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: Jordan Zimmerman [mailto:[email protected]] Sent: Thursday, April 23, 2009 3:25 PM To: [email protected] Subject: RE: Shindig API guidelines.... >at present it's more of a big application (not even a framework, just an >application). It would be nice if this was stated as early as possible in the Shindig docs and on the website/wiki. This was a major roadblock for me when I started. I anticipated Shindig to be a library and it took me weeks to figure out that it was a standalone application. Jordan Zimmerman Principal Software Architect 831.647.4712 831.214.2990 (cell) [email protected] SHOP*COMTM Shop Smart, Save Big(tm) www.shop.com This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.
