Hi Derek, I think a lot of people would agree with your points below. I myself, and may others I work with, have found it a little frustrating getting off the ground with Shindig for many of the reasons you outline below. However we need to start somewhere, if you are willing to document problems and the corresponding solutions as you encounter them, you might want to consider documenting them on the Shindig Wiki ( https://cwiki.apache.org/confluence/display/SHINDIG/Index%3bjsessionid=CA26246F597032FAAA9123CA01139E03 ). I think the documentation for Shindig and OpenSocial started out strong but has since become outdated as the spec and reference implementation has progressed. As contributors to Shindig, we should all be trying to improve the documentation as we continuously contribute to the project.
-Ryan Email: rjbax...@us.ibm.com Phone: 978-899-3041 developerWorks Profile From: Henry Saputra <henry.sapu...@gmail.com> To: dev@shindig.apache.org, Date: 06/30/2011 03:47 PM Subject: Re: Shindig support Hi Derek, These suggestions are very valuable. One way you can immediately help to improve our docs and help system is to file JIRA (https://issues.apache.org) issues for Apache Shindig project. This could help us to keep track and plan what fixes or upgrades need to be done. The Shindig community is trying to make Shindig to be a turn-key project with more pluggable customization points for easy deployment. Really appreciate and looking forward for your help to make the project better. Hope this response helps to ease your concern a little bit. - Henry On Wed, Jun 29, 2011 at 10:19 PM, Derek Houghton <de...@chuwori.co.uk> wrote: > Dear Shindig Developers, > > As someone new to Shindig, but seeing it as a useful tool to plug into a large scale bioinformatics project, I am finding it slow going enabling the functionality I require. > As brought to light in recent requests for help regarding OAuth, UserPrefs and my own requirement for implementing a database back-end there is not much to go on in the way of documentation. > I was fortunate to get some help from Evgeny who pointed me in the right direction for connecting my own back end database to Shindig. Without that detailed help my project would have got seriously behind time. Even then I had further issues with EclipseLink v Hibernate. > > My experience so far in contacting other users is that they have given up on Shindig due to lack of support/ degree of difficulty or , ironically for open source, having to pay someone else to resolve the issue. > I am sure that this is not what you intend for your project. > > I have not given up on it yet but I am concerned that if I continue to adapt Shindig for my own purposes then when I hand the project over in a few months time, I am doing so without adequate reference/help material from the apache team which my employers can fall back on. > > Is there a possibility that some of the development work goes into the production of a help system in the form of tutorials or snippets of example code being made available and maintained online? A little more than 'You have to implement class X' would be invaluable. > > Under different circumstances I would like to be able to contribute to the development of Shindig, but that is not in my remit at present. For now I am just a user. I want to be able to use your product as much 'out of the box' as possible. I would rather not have to spend a lot of time figuring out exactly where I have to plug into Shindig in order to extend or implement some apparently specific core functionality for version x/y. > Even an upfront list of what does/doesn't work out of the box would be time-saving. > > In the meantime here is a question for you: What do you think would be the best way to save multiple states of the same gadget? > ie A user views the same gadget at different times. > On each occasion the user wishes to save a preferred state. > The state that is saved involves the same parameters on each occasion - but different values. > The user would wish to recall these different states at any time. > The user would want to share these different states with friends. > > My immediate thought is to employ a naming convention to distinguish distinct states and writing the params to the app_data table (which is person specific- yes?) and then modifying the relevant database classes PersonDB etc.. to retrieve records based on the naming convention. > Perhaps there is an alternative level I should be approaching this from? > > I appreciate all the work that is being done on Shindig by the development team and hope that you view this as constructive feedback and that the interest that exists in the Shindig project in the community persists and gains momentum. > > Regards > Derek > > >