>-----Original Message----- >From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >Sent: Friday, July 13, 2012 6:50 AM >To: dev@shindig.apache.org >Cc: Florian Holzschuher >Subject: Re: AW: Shindig neo4j backend > >Hi René, > >If you'd like to contribute code back to Shindig, the first step is to >open a JIRA [1]. The second step is to create an account on the Review >Board instance [2] and post a review with your patch. Within your review >you can add the "shindig" group to send a notification of your review our >to this list.
This is the same process for Rave just s/shindig/rave > >If you're just looking for some feedback on ideas that are easier to >express via a source code patch, you can skip right to the Review Board >site and create the JIRA at a later time. > >Thanks, >-Stanton > >[1] https://issues.apache.org/jira/browse/SHINDIG >[2] https://reviews.apache.org/ > > > >From: René Peinl <rene.pe...@hof-university.de> >To: <dev@shindig.apache.org>, >Cc: "Florian Holzschuher" <fholzschuh...@hof-university.de> >Date: 07/13/2012 01:46 >Subject: AW: Shindig neo4j backend > > > >Hi, >thanks for all the good suggestions. >One last question for the moment: how exactly do we contribute our code? >Should we open a Jira issue and attach the sources? >Maybe there are new suggestions, once you've seen our code. >Regards >René > >-----Ursprüngliche Nachricht----- >Von: Henry Saputra [mailto:henry.sapu...@gmail.com] >Gesendet: Freitag, 13. Juli 2012 07:17 >An: dev@shindig.apache.org >Betreff: Re: Shindig neo4j backend > >Hi, > >Thanks for the interest at Apache Shindig and Rave projects. > >Let me try to help answering some concerns and questions you have and >maybe other people in the community could chime in. > >Looks like Apache Rave provides model database abstraction that allow plug >and play to relational database. > >The Shindig's JPA implementation is just for sample/demo purpose. The only >implementation of the OpenSocial model is only POJO classes. >Backing the data storage with Neo4J sounds like awesome idea and I believe >should be more fitting for the social links for the OpenSocial data. > >As for activitystrea.ms implementation in Shindig, its fully implemented >based on the JSON 1.0 for JavaScript and Java components. >Shindig also support PHP for the server side but the implementation is far >behind the Java counterpart. > >For portal solution proposal, I would recommend using Rave as the front >end and management module and rebind the data model with Neo4J. >Contributing back to either Rave and Shindig is welcomed and encouraged =) > >Hope this helps. > >Looking forward for contributions and awesome project with you guys. > >- Henry > >On Thu, Jul 12, 2012 at 8:25 AM, René Peinl <rene.pe...@hof-university.de> >wrote: >> Dear Shindig developers, >> >> I’m working together with my colleague Florian on a systems >> integration research project that brings together a DMS, a groupware >> system, an ERP system in an Intranet scenario and adds social media >> capabilities under the hood of a central lightweight portal (see >> requirements overview at the end of the email). >> >> >> >> For the portal, we are planning to use Shindig as the central >> component and maybe Rave as a basis for the presentation layer. Since >> social media data is inherently graph-oriented, we are planning to use >> neo4j as the storage engine for Shindig (and maybe Rave as well). >> Florian has already implemented a draft of this neo4j storage layer >> which works well for some sample data that we have generated (if >> anyone is interested we can provide the sample data and the generator >> for it), but due to simplicity reasons and to avoid additional >> conversion operations in between the storage layer is currently not >> using JPA, but directly writing the objects to the database (replacing >e.g. both PersonImpl and PersonDB). >> >> >> >> Lately, we have discovered Rave and found out that despite its close >> integration with Shindig it uses its own database abstraction and >> partly competing implementations for classes that are already present in >Shindig. >> For example there is rave.portal.model.Person which uses JPA to store >> a (incomplete compared to OpenSocial 2.0 specs) person object in the >> database and there is shindig.social.opensocial.jpa.PersonDB which >> does the same, but seems like a complete implementation of the fields >> defined in OpenSocial 2.0. >> >> >> >> My goal is to better understand the decisions behind the current >> implementation of both Shindig and Rave (I’ve posted a similar >> question on the Rave mailing list) in order to find a solution for our >> project that lets the Apache community benefit as much as possible >> from our efforts, without burdening our project too much with >non-project-specific requirements. >> >> >> >> The options we have (from my perspective) are as follows >> >> 1) Kind of forking the Shindig project and using our own neo4j >backend >> and not using Rave >> >> 2) Going one step further and integrating Rave with our own neo4j >> Shindig backend and eliminate the duplicate classes >> >> 3) Trying to use SpringData JPA abstraction layer for neo4j and >> providing some extended functionality in own classes (e.g. a >> friend-of-a-friend query could be implemented with relational DBs as >> well, but doesn’t make too much sense due to performance reasons) and >> hoping that the Rave and Shindig community are helping us to eliminate >> the duplicate implementations on JPA level. >> >> >> >> All options have their pros and cons and I’d really like to hear your >> opinion on that. If you have the feeling that our project idea is very >> specific and you don’t see any use for the results in your scenarios >> than it may be better for both sides if we are building a fork. On the >> other hand, if you think that the principle idea behind our project >> would be beneficial for your scenarios as well, we would be happy to >work together on that. >> We need e.g. some of the missing OpenSocial 2.0 features like full >> activitystrea.ms support on the data layer, which is currently not >> given in Shindig 2.5 beta2 >> (https://issues.apache.org/jira/browse/SHINDIG-1536), but we do not want >to interfere with your roadmap and release plans. >> We also found several common scenarios that e.g. MS SharePoint is >> supporting, but that are not feasible with OpenSocial 2.0 >> specification (mainly due to its focus on Internet scenarios). >> Examples are: User has checked-out a document in a DMS. For this kind >> of check-out operation, there is no post verb in the activitystrea.ms >> standard. We would be happy to bring these finding into the ongoing >> discussion about future Open Social versions. >> >> >> >> Summed up, we wanted to know how we could best cooperate with the >> existing Shindig (and Rave) community in order to quickly achieve our >> goals and let the Apache community benefit the most from our efforts. >> >> Any suggestions? >> >> Regards >> >> René >> >> >> >> >> >> ----------------------------------------------------------- >> >> Prof. Dr. René Peinl >> >> Teaching area: architecture of Web applications >> >> University of applied Sciences Hof >> >> Alfons-Goppel-Platz 1, 95028 Hof, Bavaria, Germany >> >> Tel: +49-9281-409-4820 >> >> Email: rene.pe...@hof-university.de >> >> >> >> >> >> >> >> Requirements for OpenSocial Intranet Portal >> >> >> >> >> Presentation layer >> >> >> · Portal entry page with admin predefined gadgets, customizable >by >> user >> (mostly existing in Rave 0.12) >> >> · Gadget catalog (existing in Rave 0.12) >> >> · User profile page with photo, name and other attributes. Admin >> customizable. All open social fields should be available for display. >> Gadgets can be used to show additional data like activity stream, >> friends network, bookmarks/tags, … (basic functionality available in >> Rave 0.12 /portal/app/person) >> >> · User directory with overview of existing users (including >paging >> and search) >> (not present in Rave 0.12 yet) >> >> · Ability to add friends/following people to “friends network” >(e.g. >> on profile page) >> (not present in Rave 0.12 yet) >> >> · Suggestion list for new friends based on common friends, >> interests, etc. >> (not present in Rave 0.12 yet) >> >> · Ability to set a status message >> (basic functionality available in Rave 0.12) >> >> · Ability to send a personal message to a friend >> (not present in Rave 0.12 yet, maybe possible with one of the gadgets) >> >> >> >> >> Logic layer >> >> >> · Gadget Rendering API >> (existing in Shindig 2.5 beta2) >> >> · Authentication against external identity and access management >> system (IAM) using OAuth 2.0 and SAML. >> (some references state that Apache Shiro is able to do that, but we >> haven’t seen the code implementing it) >> >> · Exposing social media data like friends, activities, … as >RESTful >> Web services >> (available in Shindig 2.5 beta2) >> >> · Exposing extended social media data like friend of a friend to >> portal gadgets as RESTful Web service >> (draft implementation available at iisys) >> >> >> >> >> Data layer >> >> >> · Full support for activitystrea.ms data storage and retrieval >at >> data object layer >> (draft implementation available at iisys, but not with JPA support) >> >> · Storing/retrieving social media data like friends, activities, >> ratings, bookmarks, tags, … in/from a graph database like neo4j (draft >> implementation available at iisys, it has to be discussed, whether it >> would be better to use SpringData JPA abstraction instead of direct >> neo4j access) >> >> · Integrating Rave and Shindig person data >> (not clear why Rave is having its own Person class which seems like a >> subset of Shindigs PersonDB) >> >> · Keeping Rave User and PageUser data consistent with IAM system >> >> · Storing Rave authorization data (gadget permissions, user >> preferences, …) in neo4j >> (not available yet) >> >> · Storing Rave general user data in neo4j. >> (not available yet) >> >> >> >> >> > >
