Re: Apache Shindig CMS Site Update
Looks good Ryan. Thanks. I also found a related YouTube video from Rob Weir outlining anonymous mode for CMS which would allow anyone to submit changes to the CMS site. http://www.youtube.com/watch?v=7fvg1pfHLhE -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/10/2012 22:02 Subject:Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
RE: Apache Shindig CMS Site Update
Hooray for bootstrap! BTW, you might want to test it in IE. Something isn't quite right, but I haven't had time to look into what that is. -Matt -Original Message- From: Ryan Baxter [mailto:rbaxte...@apache.org] Sent: Tuesday, July 10, 2012 10:03 PM To: dev@shindig.apache.org Subject: Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
Shindig neo4j backend
Dear Shindig developers, Im 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 (Ive 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 doesnt 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 Id really like to hear your opinion on that. If you have the feeling that our project idea is very specific and you dont 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) ·
Re: Apache Shindig CMS Site Update
You should make your first change to the site and add the video :) It would be good to have up there. On Thu, Jul 12, 2012 at 7:54 AM, Stanton Sievers ssiev...@us.ibm.com wrote: Looks good Ryan. Thanks. I also found a related YouTube video from Rob Weir outlining anonymous mode for CMS which would allow anyone to submit changes to the CMS site. http://www.youtube.com/watch?v=7fvg1pfHLhE -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/10/2012 22:02 Subject:Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
Re: Apache Shindig CMS Site Update
Thanks Matt, I wrote most of this testing it in Chrome and FF so I haven't looked at any other browsers. I can try and take a look when I get a chance. Kind of surprised since I changed little to nothing about the default bootstrap styles so I would think we shouldn't have a problem in the different browsers, unless there is a bug in bootstrap. -Ryan On Thu, Jul 12, 2012 at 8:05 AM, Franklin, Matthew B. mfrank...@mitre.org wrote: Hooray for bootstrap! BTW, you might want to test it in IE. Something isn't quite right, but I haven't had time to look into what that is. -Matt -Original Message- From: Ryan Baxter [mailto:rbaxte...@apache.org] Sent: Tuesday, July 10, 2012 10:03 PM To: dev@shindig.apache.org Subject: Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
RE: Apache Shindig CMS Site Update
-Original Message- From: Ryan Baxter [mailto:rbaxte...@apache.org] Sent: Thursday, July 12, 2012 12:06 PM To: dev@shindig.apache.org Subject: Re: Apache Shindig CMS Site Update Thanks Matt, I wrote most of this testing it in Chrome and FF so I haven't looked at any other browsers. I can try and take a look when I get a chance. Kind of surprised since I changed little to nothing about the default bootstrap styles so I would think we shouldn't have a problem in the different browsers, unless there is a bug in bootstrap. More likely, IE just needs a little help. We had to add some scripts to Rave (Modernizr, etc) and an x-ua-compatible head tag to get IE to behave properly... -Ryan On Thu, Jul 12, 2012 at 8:05 AM, Franklin, Matthew B. mfrank...@mitre.org wrote: Hooray for bootstrap! BTW, you might want to test it in IE. Something isn't quite right, but I haven't had time to look into what that is. -Matt -Original Message- From: Ryan Baxter [mailto:rbaxte...@apache.org] Sent: Tuesday, July 10, 2012 10:03 PM To: dev@shindig.apache.org Subject: Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
Re: Apache Shindig CMS Site Update
Wow, that was easy. http://shindig.staging.apache.org/documentation_website.html -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/12/2012 12:10 Subject:Re: Apache Shindig CMS Site Update You should make your first change to the site and add the video :) It would be good to have up there. On Thu, Jul 12, 2012 at 7:54 AM, Stanton Sievers ssiev...@us.ibm.com wrote: Looks good Ryan. Thanks. I also found a related YouTube video from Rob Weir outlining anonymous mode for CMS which would allow anyone to submit changes to the CMS site. http://www.youtube.com/watch?v=7fvg1pfHLhE -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/10/2012 22:02 Subject:Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
Re: Apache Shindig CMS Site Update
CMS for the win! On Thu, Jul 12, 2012 at 12:56 PM, Stanton Sievers ssiev...@us.ibm.com wrote: Wow, that was easy. http://shindig.staging.apache.org/documentation_website.html -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/12/2012 12:10 Subject:Re: Apache Shindig CMS Site Update You should make your first change to the site and add the video :) It would be good to have up there. On Thu, Jul 12, 2012 at 7:54 AM, Stanton Sievers ssiev...@us.ibm.com wrote: Looks good Ryan. Thanks. I also found a related YouTube video from Rob Weir outlining anonymous mode for CMS which would allow anyone to submit changes to the CMS site. http://www.youtube.com/watch?v=7fvg1pfHLhE -Stanton From: Ryan Baxter rbaxte...@apache.org To: dev@shindig.apache.org, Date: 07/10/2012 22:02 Subject:Apache Shindig CMS Site Update OK folks the staging CMS site is live at http://shindig.staging.apache.org. You can now edit the CMS site using the CMS bookmarklet directly in your browser. I have started some documentation on how to do so on Shindig's CMS site [1] :) It should be easy for people to start contributing content, I suggest you watch the short tutorial video on CMS [2] to get started. The production site is not enabled yet, so please do not publish anything to production yet. [1] http://shindig.staging.apache.org/documentation_website.html [2] http://www.youtube.com/watch?v=xcDZN3Lu6HA -Ryan
Re: Shindig neo4j backend
Welcome Rene :) Let me preface this by saying I have little knowledge of how Rave is implemented. I have been meaning to look at it more in depth but haven't had the time. I am kind of surprised Rave does not allow you to still use your own persistence mechanism if you so choose. I would think they would still keep that option available to consumers since there are endless possibilities for persisting data. If you really can't inject your own persistence model into Rave it sounds like option 1 is your best bet, but as you list out in your requirements Rave offers a ton of other functionality you want. If you chose options 1 are you really forking Shindig, or just injecting your own implementations? The two are very different. I am a little confused about your comments about the activity stream implementation. As far as I know it is a complete implementation, do you have specifics on what you think is missing? Between the Rave and Shindig community I am sure we can help you figure out which project is best for your use cases. The Shindig community will welcome any contributions you want to make in order to help Shindig fit your use cases better and we would be glad to help explain any of the current features you have questions about. A lot of us have gone through some extensive implementations and we realize the documentation around some of the feature is lacking. As far as the OpenSocial spec your contributions will be welcomed there as well, especially if you provide an implementation for it :) -Ryan On Thu, Jul 12, 2012 at 11: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
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
AW: Shindig neo4j backend
Thanks Ryan, to clarify things: Rave allows to have your own backend, it just has its own additional database abstraction and partly has persistence classes that are a subset of Shindig classes on the one hand, but add a few additional things on the other hand. Dependency injection was also recommended on the Rave mailing list. I'm no expert of DI and have used it up to now only for things like authentication or logging. Therefore, I was not considering that option. I will have a look into how that might be an option for us. On the Rave mailing list they also recommended having two databases, a relational one for portal data like which pages exist and which users have permissions on them and the graph db for social media data. Regarding the OpenSocial 2.0 missing features in Shindig it seems, that you have integrated patches from version 3.0 in current Shindig releases. I saw an open issue that already had a patch, but was scheduled for Shindig 3.0. The roadmap also stated that OpenSocial 2.0 support is scheduled for Shindig 3.0. It seems that changed in the last couple of weeks. I was specifically missing support for events http://activitystrea.ms/specs/json/schema/activity-schema.html#event But maybe I'm not up to date anymore. Sorry for that. Regards René -Ursprüngliche Nachricht- Von: Ryan Baxter [mailto:rbaxte...@apache.org] Gesendet: Freitag, 13. Juli 2012 03:28 An: dev@shindig.apache.org Cc: Florian Holzschuher Betreff: Re: Shindig neo4j backend Welcome Rene :) Let me preface this by saying I have little knowledge of how Rave is implemented. I have been meaning to look at it more in depth but haven't had the time. I am kind of surprised Rave does not allow you to still use your own persistence mechanism if you so choose. I would think they would still keep that option available to consumers since there are endless possibilities for persisting data. If you really can't inject your own persistence model into Rave it sounds like option 1 is your best bet, but as you list out in your requirements Rave offers a ton of other functionality you want. If you chose options 1 are you really forking Shindig, or just injecting your own implementations? The two are very different. I am a little confused about your comments about the activity stream implementation. As far as I know it is a complete implementation, do you have specifics on what you think is missing? Between the Rave and Shindig community I am sure we can help you figure out which project is best for your use cases. The Shindig community will welcome any contributions you want to make in order to help Shindig fit your use cases better and we would be glad to help explain any of the current features you have questions about. A lot of us have gone through some extensive implementations and we realize the documentation around some of the feature is lacking. As far as the OpenSocial spec your contributions will be welcomed there as well, especially if you provide an implementation for it :) -Ryan On Thu, Jul 12, 2012 at 11:25 AM, René Peinl rene.pe...@hof-university.de wrote: Dear Shindig developers, Im 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 (Ive 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
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),
