AW: Welcome to OpenDashboards!

[René Peinl]

Hi *,
since some of you requested a version of Shindig that is just working out of 
the box with no lengthy installation and configuration, we've finally published 
our Docker image of Shindig 2.5.2 running on Apache Tomcat 7 with Open JDK 7 
and our integration code to use neo4j (1.98) as a storage backend. 
This version has some additional enhancements compared to the original version 
like friend suggestions based on existing friends and their connections as well 
as queries to determine the connections between two people.
It can be downloaded from Docker Hub
https://hub.docker.com/r/rpeinl/shindig-ws-neo4j/
I hope that helps some of you to get up to speed. 
Feedback welcome.
Regards
René 


-Ursprüngliche Nachricht-
Von: Chris Spiliotopoulos [mailto:chrysanthos.spiliotopou...@gmail.com] 
Gesendet: Montag, 23. November 2015 11:54
An: dev@shindig.apache.org
Betreff: Welcome to OpenDashboards!

Hi friends,

after gathering all your wishes, proposals and votes on the recently created 
Trello 
board toady a new open source organization over at GitHub under the name of 
OpenDashboards  has been created that 
will be used as our common placeholder for all the things we want to see 
happening from now on.

In order to send out invitations to anyone that wishes to join this new effort, 
please make sure you have a GitHub account and post it back to me either as a 
reply to this email or directly through our new Slack 
 space (channel *github-org*).  For those who 
still haven't signed up with the OpenDashboards Slack team, please send me your 
email as well and I will send you an invitation.

Please keep in mind that although this new effort has started off as a shelter 
for the Apache Shindig project can clearly  have a bright future, since 
'dashboarding' is and will be a common requirement for many companies, 
organizations and individual technology solutions.  Having stated that, I have 
a vision that OpenDashboards can easily become the next one-stop shop for 
diverse dashboarding solutions given the appropriate context and positioning in 
the technology space.

I believe that we should all urge the companies we represent to join the effort 
and contribute to the evolution of an ecosystem we all could benefit from.  
Also, we could start building collaborations with other open source projects 
and solutions in the same space, or even with various verticals in order to 
start getting attention and traction.

Now that we have a new home, the next step is to transfer the Apache Shindig 
project to a new repository @ Github at its latest stable version.
So, @Ryan can you give us the status from your side (and Apache's of course)?  
Have you cleared things up regarding the transfer?

Best regards,
Chris




--
Chris Spiliotopoulos

Solutions Architect | @LinkedIn
| @Twitter 

AW: Terminate the Apache Shindig Project

[René Peinl]

Dear Shindig Community,
I'm also a bit sorry about the project closing, but also see it as a chance for 
something new. We tried to contribute code back to Shindig several times and 
never made it. Our last effort just got stuck in the review process with no 
arguments why it didn't make it into the main trunk (for over one year now). 
Our contributions are already published on Github. 
https://github.com/iisys-hof 
Once Shindig is officially buried, we will extend the code on Github, so that 
it is including a full Shindig with all our modifications so that anybody can 
clone, compile and run it. Currently it is a bit hard to put things from the 
Shindig repository and our Github repository together. That will be easier 
then. We didn't do a public fork yet, since we did not want to weaken the 
official project. 

I wish you all the very best and am also keen on seeing the first results from 
the W3C social web working group. Unfortunately, it seems it is again a rather 
closed "inner circle" of people. I applied for an invitation as an external 
"expert" (as they call it), got one inquiry, which I promptly answered and 
never heard anything about it since then (3 months ago). That is not my 
understanding of an open, community-driven process.

Regards
René 


-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@apache.org] 
Gesendet: Donnerstag, 8. Oktober 2015 15:08
An: dev@shindig.apache.org
Betreff: Re: Terminate the Apache Shindig Project

Hi Chris, thanks for the very thoughtful email.  In general I agree with what 
you are saying.  Some more comments inline.

On Thu, Oct 8, 2015 at 5:54 AM Chris Spiliotopoulos < 
chrysanthos.spiliotopou...@gmail.com> wrote:

> Hi all,
>
> instead of becoming emotional I prefer sharing some thoughts with 
> everyone in this thread.  Well, to be honest I think that everyone 
> expected this to happen at some point.  Of course not due to lack of 
> support from the dev team - this had always been superb - but rather 
> due to lack of awareness regarding this (IMHO) ground-breaking 
> technology and I'm referring to the gadgets side of things.
>
> I've been using gadgets for quite a few years and I've managed to 
> convince people about the benefits of having a fully decoupled system 
> with pluggable apps either in-house or 3rd party.  Of course as I have 
> stated in the past this had always been a steep curve as very few 
> people are aware of this technology but in the end everybody would buy in 
> after seeing the results.
> During these years I have managed to 'tame the beast' as resources had 
> always been scattered and very few and eventually was able to put it 
> to work for producing great dashboard apps and in the future (I hope) 
> marketplaces as well.
>
> My personal feeling is that most of the people using Shindig for a 
> long time now are here for its gadget rendering capabilities and the 
> potential it provides towards a fully decoupled architecture where app 
> devs can work independently from platform devs but eventually 
> everything can work together a a whole with minimum orchestration 
> efforts.  This has been my personal experience so far anyways.  Having 
> said that, I've always felt that the Shindig project had always been 
> to large / broad in functionality lacking clearly not dev but rather 
> promotional & awareness efforts.
>
> Another factor that always helped me rest assured in a way regarding 
> its usefulness and future  is that major companies like Google, 
> Atlassian and others with very popular products have also been using 
> this technology as a core component of their infrastructure until now.  
> Although Google who open-sourced the tech seems that it progressively 
> deprecates some of their products who had major touch points with the 
> gadgets spec, still keeps it alive in products like Gmail, Google 
> apps, etc plus they have been hosting the official Gadgets API site 
> for a long time now.  One of the puzzling questions though is why 
> these companies (apart from the IBM people who kept the project 
> running) were never openly involved with the promotion and support of 
> the tech in order to reach broader audiences through real-life use 
> cases?  Correct me if I'm wrong but I've come to the conclusion that 
> these companies are maintaining probably ports of certain Shindig components 
> that have extended them in order to meet their requirements.
> This is easy to speculate since reading the documentation of their 
> products shows clearly that there are extensions not supported by 
> Shindig out-of-the-box - once I had a chat with a guy working at Jive 
> at the time and he told me that they wrote their own security layer 
> around their gadget containers.


> I'll have to agree with Darren that due to the robustness of the 
> framework most integrators are more than ok with the standard features 
> it has to offer and therefore this might have caused the side-effect 
> to the maintainers to 

AW: Natural language version of activities in Shindig

[René Peinl]

I'm glad that you see it positively Ryan. 
I guess your concern is regarding the semantics of the activities, that might 
vary from application to application a little bit. 
However, from my perspective Shindig as a central unit should also have some 
kind of harmonization role regarding semantics. I think it is helpful to have a 
consistent set of well-defined activities and hide system-specifics up to a 
certain amount. 
I would provide a text-file with suggestions for English and German and every 
administrator that uses Shindig would be free to alter them for their setup or 
add those files for different languages. I can also imagine the Shindig 
community providing two or three different versions of that file depending on 
the application scenario like company intranets (our use case) or internet 
communities (maybe semantics are different in this case).

Finally, the feature should be configurable so it can be turned on and off by 
the administrator and of course it should not overwrite existing title 
attributes coming from the database. With these two mechanisms in place, 
everybody should be happy from my perspective. People who don't like the 
feature simply turn it off. Others that have applications in place that set the 
title on their own don't have to fear that the new feature will interfere with 
those and all the other don't have to implement own code for creating the 
natural language strings.

Please find enclosed a document that describes how we use the general 
activitystrea.ms verbs in our use case. SCHub is the project acronym denoting 
Social Collaboration Hub. That might further clarify things.


-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@gmail.com] 
Gesendet: Montag, 1. Dezember 2014 22:39
An: dev@shindig.apache.org
Betreff: Re: Natural language version of activities in Shindig

Makes sense Rene thanks.  But what I don't understand is how you propose 
Shindig be able to translate the activity, would the app creating the activity 
provide the translation?

On Mon, Dec 1, 2014 at 12:57 PM, René Peinl rene.pe...@hof-university.de 
wrote:
 Dear Ryan,
 Sorry that my description was not precise enough.
 What I want to achieve is: store actor, verb, object, and 
 target of an activity in Shindig and when retrieving the activity get a 
 JSON that delivers the stored values and in addition includes the title 
 attribute with something like {
language: en,
title:actor renamed document object into target
 }
 Shindig should use a lookup table that has a natural language template per 
 activity verb.

 With real data instead of placeholders this would look like {
language: en,
title: Peter renamed document 'meeting protocol2.pdf' into 'meeting 
 protocol for second project review.pdf'
 }

 I hope that helps. If not, please try to rephrase what you understood, so 
 that I can see where exactly the problem with understanding is.
 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ryan Baxter [mailto:rbaxte...@gmail.com]
 Gesendet: Montag, 1. Dezember 2014 17:18
 An: dev@shindig.apache.org
 Cc: Florian Holzschuher; Christian Ochsenkühn
 Betreff: Re: Natural language version of activities in Shindig

 Hi Rene,

 Can you provide a more concrete example of what you are trying to do?
 I am having a hard time grasping your question.

 On Mon, Dec 1, 2014 at 7:47 AM, René Peinl rene.pe...@hof-university.de 
 wrote:
 Dear Shindig community,

 we are facing a challange in our project, that we are using Shindig 
 to collect activities from various systems and want to show 
 activities coming from Shindig in every system. Currently Shindig 
 only delivers the basic activity data like activity verb, object, target and 
 so on.
 However, we’d like to show a natural language version of the activity 
 in the activity stream (full sentence) which includes multi-lingual 
 presentation of the contents. An example would be „actor has added 
 a comment to object“ or „actor renamed document object into 
 target“. The activitystrea.ms standard specifies the title attribute for 
 that purpose.

  http://activitystrea.ms/specs/json/1.0/#activity
 http://activitystrea.ms/specs/json/1.0/#activity

 In Shindig this attribute attribute is present and handled, but only 
 in a pass-through manner.



 In order to avoid duplication of code, our natural choice would be to 
 extend Shindig to generate the natural language version of the 
 activities in the title attribute, if title is not present in the 
 database. We would use files for translation and formatting templates 
 (only string formatting, not colouring or layout), so that every 
 administrator can influence both without any coding.



 Would this be an interesting extension for the Shindig base system 
 and do you have any suggestions on how to integrate such an extension 
 from an architecture point of view? We are e.g. not sure whether to 
 deliver several translation in the same JSON as shown here


 http://www.w3

Natural language version of activities in Shindig

[René Peinl]

Dear Shindig community,

we are facing a challange in our project, that we are using Shindig to
collect activities from various systems and want to show activities coming
from Shindig in every system. Currently Shindig only delivers the basic
activity data like activity verb, object, target and so on. However, we’d
like to show a natural language version of the activity in the activity
stream (full sentence) which includes multi-lingual presentation of the
contents. An example would be „actor has added a comment to object“ or
„actor renamed document object into target“. The activitystrea.ms
standard specifies the title attribute for that purpose. 

 http://activitystrea.ms/specs/json/1.0/#activity
http://activitystrea.ms/specs/json/1.0/#activity

In Shindig this attribute attribute is present and handled, but only in a
pass-through manner. 

 

In order to avoid duplication of code, our natural choice would be to extend
Shindig to generate the natural language version of the activities in the
title attribute, if title is not present in the database. We would use files
for translation and formatting templates (only string formatting, not
colouring or layout), so that every administrator can influence both without
any coding. 

 

Would this be an interesting extension for the Shindig base system and do
you have any suggestions on how to integrate such an extension from an
architecture point of view? We are e.g. not sure whether to deliver several
translation in the same JSON as shown here

 
http://www.w3.org/TR/2014/WD-activitystreams-core-20141023/#naturalLanguage
Values
http://www.w3.org/TR/2014/WD-activitystreams-core-20141023/#naturalLanguageV
alues

or use a parameter from the client to choose the language. 

My guess would be that other people will face similar problems.

 

Regards

René

 

AW: Natural language version of activities in Shindig

[René Peinl]

Dear Ryan,
Sorry that my description was not precise enough. 
What I want to achieve is: store actor, verb, object, and target of an 
activity in Shindig and when retrieving the activity get a JSON that delivers 
the stored values and in addition includes the title attribute with something 
like 
{ 
   language: en,
   title:actor renamed document object into target
}
Shindig should use a lookup table that has a natural language template per 
activity verb.

With real data instead of placeholders this would look like
{
   language: en,
   title: Peter renamed document 'meeting protocol2.pdf' into 'meeting 
protocol for second project review.pdf'
}

I hope that helps. If not, please try to rephrase what you understood, so that 
I can see where exactly the problem with understanding is.
Regards
René

-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@gmail.com] 
Gesendet: Montag, 1. Dezember 2014 17:18
An: dev@shindig.apache.org
Cc: Florian Holzschuher; Christian Ochsenkühn
Betreff: Re: Natural language version of activities in Shindig

Hi Rene,

Can you provide a more concrete example of what you are trying to do?
I am having a hard time grasping your question.

On Mon, Dec 1, 2014 at 7:47 AM, René Peinl rene.pe...@hof-university.de wrote:
 Dear Shindig community,

 we are facing a challange in our project, that we are using Shindig to 
 collect activities from various systems and want to show activities 
 coming from Shindig in every system. Currently Shindig only delivers 
 the basic activity data like activity verb, object, target and so on. 
 However, we’d like to show a natural language version of the activity 
 in the activity stream (full sentence) which includes multi-lingual 
 presentation of the contents. An example would be „actor has added a 
 comment to object“ or „actor renamed document object into 
 target“. The activitystrea.ms standard specifies the title attribute for 
 that purpose.

  http://activitystrea.ms/specs/json/1.0/#activity
 http://activitystrea.ms/specs/json/1.0/#activity

 In Shindig this attribute attribute is present and handled, but only 
 in a pass-through manner.



 In order to avoid duplication of code, our natural choice would be to 
 extend Shindig to generate the natural language version of the 
 activities in the title attribute, if title is not present in the 
 database. We would use files for translation and formatting templates 
 (only string formatting, not colouring or layout), so that every 
 administrator can influence both without any coding.



 Would this be an interesting extension for the Shindig base system and 
 do you have any suggestions on how to integrate such an extension from 
 an architecture point of view? We are e.g. not sure whether to deliver 
 several translation in the same JSON as shown here


 http://www.w3.org/TR/2014/WD-activitystreams-core-20141023/#naturalLa
 nguage
 Values
 http://www.w3.org/TR/2014/WD-activitystreams-core-20141023/#naturalLan
 guageV
 alues

 or use a parameter from the client to choose the language.

 My guess would be that other people will face similar problems.



 Regards

 René

AW: 2.5.2 release?

[René Peinl]

Would this be a good time to include our neo4j patch?
https://issues.apache.org/jira/browse/SHINDIG-1911
https://reviews.apache.org/r/9773/


-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@gmail.com] 
Gesendet: Montag, 10. November 2014 15:44
An: dev@shindig.apache.org
Betreff: Re: 2.5.2 release?

I have no problem doing a release whenever.  The problem is always trying to 
find some time to do them ;)  I will try to kick one off this week.

On Sat, Nov 8, 2014 at 12:26 PM, Stanton Sievers ssiev...@apache.org wrote:
 Hi Doug,

 There's no set time frame on the 2.5.2 release.  If we think there are 
 enough fixed items to warrant a release then it's worth discussing.  
 As you mentioned, there are 6 items fixed in 2.5.2 right now [1].

 Personally, I think the mindset should be if we are in doubt whether 
 or not it's time to cut a release then cut a release.  It doesn't hurt 
 to get fixes out there, IMO.

 What does everyone else think?

 Thanks,
 -Stanton

 [1]
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20A
 ND%20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%
 20BY%20priority%20DESC

 On Fri, Nov 7, 2014 at 9:26 AM, Davies,Douglas davi...@oclc.org wrote:

 It's been about 8 months since the last release.  I see there are 
 only about 6 out of the 25 tickets that have been resolved for 2.5.2.  
 What is the roadmap for releasing 2.5.2?  Is it determined by 
 timeframe or bugs fixed?  I have a patch I contributed that we'd 
 really like to get into our project, but I don't want to cause anyone 
 unnecessary time to do a build if it's not time.

 Thanks,
 Doug

AW: Implementation Guide

[René Peinl]

Hi Raj,
we are using Shindig in our project for collecting events from Liferay, XWiki, 
Alfresco and OpenXchange and presenting them as an Activity Stream inside a 
Liferay portlet. We are using the neo4j Backend we contributed as a storage 
solution. This allows us to offer social networking that provides friend 
suggestions and shows the shortest path between two people not directly 
connected, both as a Liferay portal. 
I could contribute a case description to the implementation guide, if you like. 
A demo with these systems will be available early 2015 I guess. 
Regards
René

-Ursprüngliche Nachricht-
Von: Raj Janorkar [mailto:raj.janor...@gmail.com] 
Gesendet: Donnerstag, 9. Oktober 2014 01:53
An: dev@shindig.apache.org
Betreff: Re: Implementation Guide

Hi Ryan,

I think we need

1) Great Logo for shindig
2) Attractive yet simple template for doco.
3) Few shindig implementations on web, this will help users to understand how 
shindig work and what extend it can be enhanced.

These will help shindig to attract new users/developers.

Sorry i do not have skill to develop logo. If we dont get any i am happy to 
find some font which will look good for name shindig, let me know.


Regards,
Raj

On Thu, Oct 9, 2014 at 6:33 AM, Ryan Baxter rbaxte...@apache.org wrote:

 Chris many other popular apache projects keep the project 
 documentation on the project sitetake a look at Apache HTTP, 
 Apache Tomcat, and Apache Hadoop.  Not sure if they have all moved 
 over to Apache CMS or not but I would rather stick with the 
 convention.

 Agree on a new logo, if anyone has the skills to come up with one that 
 would be great.

 On Wed, Oct 8, 2014 at 4:17 AM, Chris Spiliotopoulos 
 chrysanthos.spiliotopou...@gmail.com wrote:
  Hi all,
 
  the question is how we should balance the material between Apache 
  CMS and Confluence.  I think that all technical guides and resources 
  should go
 into
  Confluence - making it the official documentation space, rather than
 just a
  wiki - and all the high-level reference / 'marketing' / news 
  material
 into
  the web site.
 
  I'm having a look at different Bootstrap themes in order to select a 
  few, submit the initial list and let the people involved decide.  As 
  I've already said, I think we should use a vibrant theme that shouts 
  Hey,
 have
  a look inside. It's good stuff! therefore my attention is grabbed 
  by 'landing page' / 'agency' parallax type themes.
 
  One thing that is missing though, is a kick-ass Shindig logo.  Is 
  someone willing to create one?  Raj, if you could suggest a 
  Bootstrap theme that would be great.
 
  In the following days, I'll post a selection of themes as a 
  reference and we can vote.  Also, I'll try and write down a 
  suggested link structure
 for
  the new site and also a scaffolding for the technical docs in Confluence.
 
  Let me know what you think.
 
  Cheers,
  Chris
 
  On Wed, Oct 8, 2014 at 2:27 AM, Ryan Baxter rbaxte...@apache.org
 wrote:
 
  OK well for reference check out the website docs [1].  Let me know 
  if you have any problems.
 
  [1] http://shindig.apache.org/documentation_website.html
 
  On Tue, Oct 7, 2014 at 7:24 PM, Raj Janorkar 
  raj.janor...@gmail.com
  wrote:
   Hi Ryan,
  
   In my work place i am using Confluence. so i don't think there 
   will be problem to me.
  
   Regards,
   Raj
  
   On Tue, Oct 7, 2014 at 7:17 AM, Ryan Baxter rbaxte...@gmail.com
 wrote:
  
   Chris and Raj, appreciate you both stepping up!  Are you 
   familiar
 with
   how to use Apache CMS to edit the Shindig site?
  
   On Thu, Oct 2, 2014 at 7:09 AM, Raj Janorkar 
   raj.janor...@gmail.com
 
   wrote:
I am also in.
though i am new here but ready to help wherever i can.
   
Thank you for this great step.
   
On Thu, Oct 2, 2014 at 7:14 PM, Chris Spiliotopoulos  
chrysanthos.spiliotopou...@gmail.com wrote:
   
Hi all,
   
I am willing to take the first step forward on this but I 
expect
 all
the
people in this group to contribute / suggest / vote on 
important
  things
that will make the Shindig project come back to life and 
start receiving attention.  Based on the steps that Ryan 
suggested:
   
   
 *1.  We use the Shindig site as the place to keep the
  documentation.
 It
is
 CMS based [1] so no need to know how to write HTML.*
   
   
First we need to decide on an awesome  clean theme for the
 website
that
will be responsive and attractive.  As Bootstrap is already 
being
  used
that
should be no prob, but we need to use a theme that will rock.
 Please
suggest themes from other sites that you find attractive and 
user friendly.  For instance, I find the SailsJS 
http://sailsjs.org/
  theme
very clear for reading.  Also, if someone could deal with the 
art
  work
that
would be very useful.
   
   
   

 *2.  We create a getting started guide, containing the 
 minimal

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

 On May 26, 2014, 3:29 p.m., Stanton Sievers wrote:
  I verified that the patch applies cleanly, although IntelliJ had some path 
  issues that needed manual correction.  I built with the websocket-backend 
  profile enabled and verified that a war file was produced, the contents of 
  which looked correct.
  
  Ryan had some questions in an earlier comment about properties file and the 
  sample data that I would like to see addressed.
  
  Other than that, I think this is in a state where we can commit it.  It is 
  sufficiently roped-off via the profile that the risk is low.

Thanks Stanton.
Regarding the issues you mention:

- sample data: as described in the readme on github 
https://github.com/iisys-hof/neo4j-websocket-server/blob/master/README the 
servlet container is optional. That means, you can run either the war file in a 
servlet container like Glassfish 4 or use a normal Java SE JRE. In the latter 
case, the Tyrus Web socket library (included in the dependencies-jars folder) 
will be used to establish the connection. 
The sample data provided on dropbox 
https://dl.dropboxusercontent.com/u/32445341/neo4j.zip should be extracted to a 
local directory and this directory has to be specified in the 
neo4j-websocket-server.properties as described in step 3 in the readme.

- properties file: there should not be a neo4j-websocket-server.properites file 
in the Shindig project and neither was there in all our tests. We cannot 
reproduce this behavior. Maybe it is due to the platform. We have only tested 
several Linux versions. Our main development line is Ubuntu 12.04. We could 
also test on Windows 7, but you already did that and it works there as well. We 
don't have a Mac OS X test environment unfortunately.


- René


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9773/#review43936
---


On April 8, 2014, 1:45 p.m., René Peinl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9773/
 ---
 
 (Updated April 8, 2014, 1:45 p.m.)
 
 
 Review request for shindig.
 
 
 Bugs: Shindig-1911
 https://issues.apache.org/jira/browse/Shindig-1911
 
 
 Repository: shindig
 
 
 Description
 ---
 
 Review for Shindig-1911
 Alternative database backend based on graph database neo4j
 Any comments welcome. We are committed to further improve this.
 
 
 Diffs
 -
 
   /trunk/java/websocket-backend/LICENSE PRE-CREATION 
   /trunk/java/websocket-backend/NOTICE PRE-CREATION 
   /trunk/java/websocket-backend/README PRE-CREATION 
   /trunk/java/websocket-backend/pom.xml PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/Constants.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GraphAPIModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GuiceModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/WebsockConfig.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ExtOrgPersonImpl.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ExtOrganizationImpl.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/IExtOrgPerson.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/IExtOrganization.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ADataTransferObject.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AccountDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ActivityEntryDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ActivityObjectDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AddressDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AlbumDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/DTOHelper.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/GroupDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main

AW: Review of Neo4j patch

[René Peinl]

If you can be more specific on what exactly is not well documented enough to be 
easy to set up, we will surely enhance the documentation in these areas. 
However, we have already improved it since the last conversation about this 
issue a few months ago.

-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@gmail.com] 
Gesendet: Freitag, 23. Mai 2014 16:17
An: dev@shindig.apache.org
Betreff: Re: Review of Neo4j patch

I echo Stanton's comments.  The last time I tried to use the patch I was still 
having trouble figuring out how to get everything up and running.  I can try to 
find some time to take a look again.  Sorry to be so slow on this.

On Wed, May 21, 2014 at 9:04 AM, Stanton Sievers ssiev...@apache.org wrote:
 Hi René,

 I'm sorry that this has been your experience.  Please don't interpret 
 the slow-moving process as a lack of appreciation for the work you've 
 done.  It is very much appreciated, I promise you.

 Given the state of the patch and the conversation on the review, I 
 think we need to just get this committed so that work can continue in 
 smaller, more manageable chunks.

 For my own part, I'll aim to play around with things over the upcoming 
 long weekend here in the states.

 Thanks,
 -Stanton



 On Wed, May 21, 2014 at 8:28 AM, René Peinl 
 rene.pe...@hof-university.dewrote:

 Dear Shindig Community,

 I’d like to bring our contribution regarding a proper database 
 backend for Apache Shindig to your attention.

 As some of you might know, we already posted an initial patch over a 
 year ago. It turned out, that it was not feasible to include this in 
 Shindig due to licensing issues that we were not aware of before.

 https://issues.apache.org/jira/browse/SHINDIG-1911

 A few months later we asked via the mailing list, whether you would 
 be still interested in getting a patch which circumvents these issues 
 and I received positive feedback from you.

 4 months ago, we posted a new version of the patch which sorted out 
 the licensing issues and had some other significant enhancements 
 regarding multi-threading, multiple concurrent connections and things 
 like that, that make it ready for larger installations with multiple db 
 servers.

 https://reviews.apache.org/r/9773/

 Initially, Ryan Baxter gave us some good hints regarding minor issues 
 with documentation and installation. We’ve sorted them out, but 
 during the last three months there were no visible efforts from the 
 Shindig-side to really bring this patch into the main code. We are 
 still committed to support and further enhance it, so if there are 
 reasonable issues, please let us know.



 I’d like to communicate my frustration and disappointment about the 
 procedure. I don’t know the reasons for the way this issue is handled 
 and I’m sure you all have important things to do, but I can’t imagine 
 how any open source project can work that simply ignores 
 contributions worth several person months of work.

 Please give this patch a fair chance.

 Regards

 René







 Prof. Dr. René Peinl

 Teaching area: architecture of Web applications

 Hof University

 Alfons-Goppel-Platz 1

 95028 Hof

 Germany



 Tel:  +49 9281 409-4820

 mailto:  mailto:rene.pe...@hof-university.de
 rene.pe...@hof-university.de

Review of Neo4j patch

[René Peinl]

Dear Shindig Community,

I’d like to bring our contribution regarding a proper database backend for
Apache Shindig to your attention.

As some of you might know, we already posted an initial patch over a year
ago. It turned out, that it was not feasible to include this in Shindig due
to licensing issues that we were not aware of before. 

https://issues.apache.org/jira/browse/SHINDIG-1911 

A few months later we asked via the mailing list, whether you would be still
interested in getting a patch which circumvents these issues and I received
positive feedback from you.

4 months ago, we posted a new version of the patch which sorted out the
licensing issues and had some other significant enhancements regarding
multi-threading, multiple concurrent connections and things like that, that
make it ready for larger installations with multiple db servers. 

https://reviews.apache.org/r/9773/

Initially, Ryan Baxter gave us some good hints regarding minor issues with
documentation and installation. We’ve sorted them out, but during the last
three months there were no visible efforts from the Shindig-side to really
bring this patch into the main code. We are still committed to support and
further enhance it, so if there are reasonable issues, please let us know. 

 

I’d like to communicate my frustration and disappointment about the
procedure. I don’t know the reasons for the way this issue is handled and
I’m sure you all have important things to do, but I can’t imagine how any
open source project can work that simply ignores contributions worth several
person months of work. 

Please give this patch a fair chance. 

Regards

René 

 

 

 

Prof. Dr. René Peinl

Teaching area: architecture of Web applications

Hof University

Alfons-Goppel-Platz 1

95028 Hof

Germany

 

Tel:  +49 9281 409-4820

mailto:  mailto:rene.pe...@hof-university.de rene.pe...@hof-university.de

 

 

 

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeFriendSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeGraphSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeGroupSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeMessageSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativePersonSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/util/CollOptsConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/MultiWebSocketConnectorTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/TestWebsocketServer.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/WebsocketConnectorTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/BasicQueryHandlerTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/FakeWebsockSession.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/MessageFutureTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/MultiConnQueryHandlerTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/NopMessageHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/ResultFutureTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/TestMessageHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/TestQueryHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/BinaryTransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/BsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/JsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/StringTransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/TransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/ListResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/SingleResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/TableResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/BsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/ImplUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JSONListTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JSONMapTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/ResultSetConverterTest.java
 PRE-CREATION 
  /trunk/pom.xml 1585650 

Diff: https://reviews.apache.org/r/9773/diff/


Testing
---


File Attachments


Neo4j-Blogpost-v3.odt
  
https://reviews.apache.org/media/uploaded/files/2014/02/04/cab9b5b9-ce49-4e0b-b36b-8e6f0b2cb056__Neo4j-Blogpost-v3.odt


Thanks,

René Peinl

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/MultiWebSocketConnectorTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/TestWebsocketServer.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/WebsocketConnectorTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/BasicQueryHandlerTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/FakeWebsockSession.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/MessageFutureTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/MultiConnQueryHandlerTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/NopMessageHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/ResultFutureTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/TestMessageHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/queries/TestQueryHandler.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/BinaryTransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/BsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/JsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/StringTransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/query/encoding/TransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/ListResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/SingleResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/result/TableResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/BsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/ImplUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JSONListTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JSONMapTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/JsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/websock/util/ResultSetConverterTest.java
 PRE-CREATION 
  /trunk/pom.xml 1578387 

Diff: https://reviews.apache.org/r/9773/diff/


Testing
---


File Attachments


Neo4j-Blogpost-v3.odt
  
https://reviews.apache.org/media/uploaded/files/2014/02/04/cab9b5b9-ce49-4e0b-b36b-8e6f0b2cb056__Neo4j-Blogpost-v3.odt


Thanks,

René Peinl

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

 On Feb. 13, 2014, 2:59 p.m., Ryan Baxter wrote:
  /trunk/java/websocket-backend/pom.xml, line 150
  https://reviews.apache.org/r/9773/diff/5/?file=433348#file433348line150
 
  Shouldn't these just point to the SNAPSHOT and not specifically to 
  update1?

I've uploaded a new diff, which refers to version 2.5.2-SNAPSHOT now.


- René


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9773/#review34367
---


On March 17, 2014, 3:13 p.m., René Peinl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9773/
 ---
 
 (Updated March 17, 2014, 3:13 p.m.)
 
 
 Review request for shindig.
 
 
 Bugs: Shindig-1911
 https://issues.apache.org/jira/browse/Shindig-1911
 
 
 Repository: shindig
 
 
 Description
 ---
 
 Review for Shindig-1911
 Alternative database backend based on graph database neo4j
 Any comments welcome. We are committed to further improve this.
 
 
 Diffs
 -
 
   /trunk/java/websocket-backend/LICENSE PRE-CREATION 
   /trunk/java/websocket-backend/NOTICE PRE-CREATION 
   /trunk/java/websocket-backend/README PRE-CREATION 
   /trunk/java/websocket-backend/pom.xml PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/Constants.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GraphAPIModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GuiceModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/WebsockConfig.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ExtOrgPersonImpl.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ExtOrganizationImpl.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/IExtOrgPerson.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/IExtOrganization.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ADataTransferObject.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AccountDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ActivityEntryDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/ActivityObjectDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AddressDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/AlbumDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/DTOHelper.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/GroupDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/MediaItemDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/MediaLinkDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/MessageCollectionDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/MessageDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/OrganizationDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/dto/PersonDTO.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ws/GraphListFieldList.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ws/PersonObjectNodeWrapper.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/service/ExtPersonHandler.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/service/UserHandler.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/servlet

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

 On Jan. 9, 2014, 1:08 a.m., Ryan Baxter wrote:
  Rene I guess I am a little confused, how could we ever apply this patch to 
  Shindig if it would require additional software to run Shindig with it?
 
 René Peinl wrote:
 Ryan, now I'm a little confused too. I guess you would do it the same way 
 as you did before with MySQL or any other database server. You would download 
 the JAR files or compile the code, which is open source. 
 For your convenience, we have put everything in a package on dropbox. 
 https://dl.dropboxusercontent.com/u/32445341/WebsocketServer.zip
 Just extract it, add the data we referenced in the previous comment and 
 run the jar file. 
 
 Our Shindig module is an optional one, so if any user decides not to use 
 it there is no problem. (It will only be compiled when the profile 
 websocket-backend is specified as can be seen in the pom file)
 
 We forgot to provide some user IDs from our sample dataset so you can 
 formulate some requests.
 The IDs are effectively integers; the range from 0 to 200 should be 
 filled completely.
 
 Ryan Baxter wrote:
 Rene, I went back and read thought the README in the patch and after 
 reading this I wondered if you have considered creating a separate upstream 
 project for this?  There is a lot of manual manipulation of the code and then 
 you have to repackage everything.  With an upstream project you don't have to 
 worry about doing any of this, you ca have your own web app the demonstrated 
 the graph db implementation.  Also I assume that if you were to put this on 
 github you would avoid the legal issues with neo4j and be able to include the 
 dependencies.
 
 René Peinl wrote:
 Ryan, thanks for your comments. I can't really believe that you don't 
 want to include our patch although it would give Shindig a proper database 
 backend, which it doesn't have currently and we explicitly asked whether you 
 would like to have it before we started. The last comment from you on 25th of 
 July 2013 was: I think Rene can move forward with his proposal. What made 
 you change your mind?
 If it is only a problem of how to compile it with the rest of Shindig, 
 I'm sure we can work it out together. Maybe Florian's description is not the 
 best way to do it. I think if you compile our code together with the rest if 
 Shindig before packaging the WAR file then there would be no need to 
 repackage. Florian took the old JPA backend and it's deployment as an example 
 for his own description. 
 Please reconsider this.

 
 Ryan Baxter wrote:
 Rene, by no means am I saying we can't deliver the patch I am just trying 
 to solve the problem of making it as easy as possible to use it.  Could we 
 create another maven project that produces a war containing a web xml with 
 the correct guice modules?
 
 René Peinl wrote:
 That seems like a good solution to me. We will work on that.

We've updated the patch attached to the issue, so that a war file is built. The 
default values for the configuration files should fit with the demo database we 
have provided. For changes in the configuration files you will still need to 
extract them from the war file and add them after editing. 


- René


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9773/#review31420
---


On Jan. 8, 2014, 1:37 p.m., René Peinl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9773/
 ---
 
 (Updated Jan. 8, 2014, 1:37 p.m.)
 
 
 Review request for shindig.
 
 
 Bugs: Shindig-1911
 https://issues.apache.org/jira/browse/Shindig-1911
 
 
 Repository: shindig
 
 
 Description
 ---
 
 Review for Shindig-1911
 Alternative database backend based on graph database neo4j
 Any comments welcome. We are committed to further improve this.
 
 
 Diffs
 -
 
   /trunk/java/websocket-backend/LICENSE PRE-CREATION 
   /trunk/java/websocket-backend/NOTICE PRE-CREATION 
   /trunk/java/websocket-backend/README PRE-CREATION 
   /trunk/java/websocket-backend/pom.xml PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/Constants.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GraphAPIModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/GuiceModule.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/WebsockConfig.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend/src/main/java/org/apache/shindig/social/websockbackend/model/ExtOrgPersonImpl.java
  PRE-CREATION 
   
 /trunk/java/websocket-backend

Re: Review Request 9773: Alternative database backend based on graph database neo4j

[René Peinl]

/BsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/query/encoding/JsonMessageHandlersTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/query/encoding/StringTransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/query/encoding/TransferUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/result/ListResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/result/SingleResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/result/TableResultTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/BsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/ImplUtilTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/JSONListTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/JSONMapTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/JsonConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/de/hofuniversity/iisys/neo4j/websock/util/ResultSetConverterTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/model/dto/ActivityEntryDTOTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/model/dto/GroupDTOTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/model/dto/MessageCollectionDTOTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/model/dto/MessageDTOTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/model/dto/PersonDTOTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/service/UserHandlerTest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WSNativeMediaItemSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeActivityStreamSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeAlbumSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeAppDataSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeFriendSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeGraphSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeGroupSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativeMessageSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/spi/WsNativePersonSPITest.java
 PRE-CREATION 
  
/trunk/java/websocket-backend/src/test/java/org/apache/shindig/social/websockbackend/util/CollOptsConverterTest.java
 PRE-CREATION 
  /trunk/pom.xml 1556165 

Diff: https://reviews.apache.org/r/9773/diff/


Testing
---


Thanks,

René Peinl

AW: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

That's still subject to discussion. As you see, we are pursuing two goals:
contribute to the Shindig project and do some research. 
Our first comparison was between SQL, Cypher, Gremlin and neo4j native API
regarding speed and maintainability of the code. We found out, that Cypher
is a good compromise.
For this next step we want to experiment with different network protocols
and payload types. In our first comparison, we found out that the existing
REST interface of neo4j is not performing very well. Neo technologies has
enhanced it since then, but we envision comparing a Web socket connection
with the existing http connection and a raw TCP socket connection regarding
speed. For the payload we are looking at JSON (currently used in neo4j),
BSON and an own object serialization. 
The last comparison will deal with the commands passed from Shindig to
neo4j. The obvious choice is Cypher, since this is becoming the default
language for neo4j, but we also want to experiment with kind of stored
procedures (not currently supported in neo4j), where we only transfer the
name of the query and the parameters. The implementation could then be
Cypher or native api on the neo4j side.
Any suggestions?
Regards
René
P.S.: Another interesting thing would be to experiment with asynchronous,
non-blocking database connections, but I guess that doesn't make sense, as
long as the rest of Shindig uses blocking calls.

-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@apache.org] 
Gesendet: Donnerstag, 18. Juli 2013 22:31
An: dev@shindig.apache.org
Betreff: Re: Review Request: Alternative database backend based on graph
database neo4j

Great.  So what technically will the code that is contributed to Shindig do?
How does it talk to the neo4j backend?

On Thu, Jul 18, 2013 at 9:25 AM, René Peinl rene.pe...@hof-university.de
wrote:
 Dear Ryan,
 fair question. The main contribution is to allow usage of neo4j as an 
 alternative database backend which improves performance significantly 
 in some areas compared to ORM and MySQL (see 
 http://www.edbt.org/Proceedings/2013-Genova/papers/workshops/a29-holzs
 chuher
 .pdf).
 In addition to that, we have also implemented some of the missing 
 features from Open Social 2.0 like adding friends to the friend 
 network and some additional features not mentioned in the Open Social 
 specification, but state-of-the-art in social networks like friend and 
 group recommendations based on friends in common and groups of friends.
 The limitation is, that these do only work or are only tested with 
 neo4j backend.
 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ryan Baxter [mailto:rbaxte...@apache.org]
 Gesendet: Mittwoch, 17. Juli 2013 02:32
 An: dev@shindig.apache.org
 Cc: Ate Douma; Peter Neubauer; Florian Holzschuher
 Betreff: Re: Review Request: Alternative database backend based on 
 graph database neo4j

 The split proposal sounds like a good approach, but what exactly would 
 be contributed to Shindig?

 On Tue, Jul 16, 2013 at 9:46 AM, René Peinl 
 rene.pe...@hof-university.de
 wrote:
 Dear Ate, dear Shindig developers,
 it's been some time since this discussion because we were a bit 
 frustrated and the project on our side was frozen for some time.
 Fortunately, I came up with an idea of how to circumvent this problem 
 and this time wanted to do the legal check BEFORE we start the coding.

 The current code has a direct compilation dependency on either neo4j 
 directly or at least their REST/JSON wrapper, which is also GPLv3
 licensed.
 That seems to be the problem.
 We therefore propose to split our code into two parts. One part 
 should become part of the Apache Shindig project and will be licensed
APLv2.
 The other part will directly use neo4j and therefore be licensed 
 under
 GPLv3 and published on sourceforge or somewhere. Between those two 
 parts there will be only network communication, no compilation
dependency.

 Could somebody from the core team please confirm, that
 a) this new proposal will have no licensing problem (my German 
 lawyer, who is specialized in OSS licensing confirmed that, but the 
 ASF may still see it
 differently)
 b) the community is still interested in the neo4j backend as an 
 option for Shindig

 Otherwise, we would not invest any more time in this issue.
 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ate Douma [mailto:a...@douma.nu]
 Gesendet: Mittwoch, 27. März 2013 15:22
 An: dev@shindig.apache.org
 Cc: Peter Neubauer; René Peinl; Florian Holzschuher
 Betreff: Re: Review Request: Alternative database backend based on 
 graph database neo4j

 Sorry about top posting (and dropping legal-discuss@) but as we 
 didn't get any feedback yet on the below question from 
 legal-discuss@, I've dived into it myself a bit further.

 I already came to the conclusion (and discussed this internally with 
 another ASF
 member) that the current proposed contribution which directly uses 
 Neo4J
 GPL3 licensed APIs cannot be allowed

AW: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

Dear Ryan,
fair question. The main contribution is to allow usage of neo4j as an
alternative database backend which improves performance significantly in
some areas compared to ORM and MySQL (see
http://www.edbt.org/Proceedings/2013-Genova/papers/workshops/a29-holzschuher
.pdf). 
In addition to that, we have also implemented some of the missing features
from Open Social 2.0 like adding friends to the friend network and some
additional features not mentioned in the Open Social specification, but
state-of-the-art in social networks like friend and group recommendations
based on friends in common and groups of friends.
The limitation is, that these do only work or are only tested with neo4j
backend.
Regards
René 

-Ursprüngliche Nachricht-
Von: Ryan Baxter [mailto:rbaxte...@apache.org] 
Gesendet: Mittwoch, 17. Juli 2013 02:32
An: dev@shindig.apache.org
Cc: Ate Douma; Peter Neubauer; Florian Holzschuher
Betreff: Re: Review Request: Alternative database backend based on graph
database neo4j

The split proposal sounds like a good approach, but what exactly would be
contributed to Shindig?

On Tue, Jul 16, 2013 at 9:46 AM, René Peinl rene.pe...@hof-university.de
wrote:
 Dear Ate, dear Shindig developers,
 it's been some time since this discussion because we were a bit 
 frustrated and the project on our side was frozen for some time. 
 Fortunately, I came up with an idea of how to circumvent this problem 
 and this time wanted to do the legal check BEFORE we start the coding.

 The current code has a direct compilation dependency on either neo4j 
 directly or at least their REST/JSON wrapper, which is also GPLv3
licensed.
 That seems to be the problem.
 We therefore propose to split our code into two parts. One part should 
 become part of the Apache Shindig project and will be licensed APLv2. 
 The other part will directly use neo4j and therefore be licensed under 
 GPLv3 and published on sourceforge or somewhere. Between those two 
 parts there will be only network communication, no compilation dependency.

 Could somebody from the core team please confirm, that
 a) this new proposal will have no licensing problem (my German lawyer, 
 who is specialized in OSS licensing confirmed that, but the ASF may 
 still see it
 differently)
 b) the community is still interested in the neo4j backend as an option 
 for Shindig

 Otherwise, we would not invest any more time in this issue.
 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ate Douma [mailto:a...@douma.nu]
 Gesendet: Mittwoch, 27. März 2013 15:22
 An: dev@shindig.apache.org
 Cc: Peter Neubauer; René Peinl; Florian Holzschuher
 Betreff: Re: Review Request: Alternative database backend based on 
 graph database neo4j

 Sorry about top posting (and dropping legal-discuss@) but as we didn't 
 get any feedback yet on the below question from legal-discuss@, I've 
 dived into it myself a bit further.

 I already came to the conclusion (and discussed this internally with 
 another ASF
 member) that the current proposed contribution which directly uses 
 Neo4J
 GPL3 licensed APIs cannot be allowed, as that (source) dependency will 
 enforce the
 GPL3 license upon this contribution as a whole, optional or not.

 The possible 'workaround' of using a 3rd party library like 
 spring-data-neo4j
 (only) which is ALv2 licensed I am also very doubtful about, because 
 that library itself has direct usage and dependency on the Neo4J APIs, 
 so it really is only 'hiding' the same problem.
 If this is a correct assumption, and I created an specific JIRA 
 question [1] for legal-discuss@ for it, then the spring data 
 'workaround' is also tainted and not to be allowed either.

 I've also brought this forward to someone at Apache Camel which intend 
 to (but hasn't yet) release a Camel Neo4J component, and it looks like 
 they will decide also that Neo4J cannot be supported after all, at the
ASF.

 Pending the resolution of [1], it now seems doubtful to me Apache 
 Shindig can accept the neo4j support contribution.
 If this becomes the case, I see two possible solutions, in preferred 
 order (besides dropping it):

 a) NeoTechnology provides an additional (probably API only) library of 
 its own under an ALv2 compatible license, which can be used to create 
 integrations like these. This would be the most practical and 
 beneficial solution IMO, similar to for instance the MongoDB (AGPL3 
 licensed) mongodb-java-driver library which is
 ALv2 licensed, see [2].

 b) Provide the Shindig Neo4J support in a separate project outside the 
 ASF, maybe at Apache Extras [3]. Downside of this of course is that 
 alignment with Apache Shindig itself will be more difficult and likely 
 trailing the development @Shindig.

 I'll keep the list noted on any progress or conclusion of [1].

 Regards, Ate

 [1] https://issues.apache.org/jira/browse/LEGAL-162
 [2] https://github.com/mongodb/mongo-java-driver
 [3] http://community.apache.org/apache-extras/faq.html

 On 03/11/2013 11:09

Interoperability with Lotus Notes 9 / IBM Connections 4

[René Peinl]

Dear Shindig developers,

during CeBit, a big German trade fair, I visited the IBM booth and asked
them about a possible interoperability between their new products which are
said to implement OpenSocial 2.0 and Shindig/Rave. Since no technical guy
was available I got the information later on and the answer was: currently,
there is no interoperability but there will be an experts circle soon that
discusses the possibility. 

I only got this little piece of information and also not directly from a
technical person, but intermediated through a sales person. Therefore, I
wanted to ask the IBM people on the mailing list how much of this
information is true. I was thinking about Notes delivering activity
information to Shindig or the other way around Open Source software like
XWiki delivering their activity information via OpenSocial to
Notes/Connections instead of Shindig. I was a little bit astonished by the
distinct “no interoperability” which is in contrast to the claimed
OpenSocial compatibility from my perspective.

Regards

René

 

AW: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

Good to know, but that doesn't solve the problem for Camel, does it? 
What difference does it make to have APL = APL = GPL or directly APL =
GPL coupling?
It just shifts the problem from Shindig or Camel to SpringData.

-Ursprüngliche Nachricht-
Von: Chris Geer [mailto:ch...@cxtsoftware.com] 
Gesendet: Montag, 11. März 2013 15:08
An: dev@shindig.apache.org
Betreff: Re: Review Request: Alternative database backend based on graph
database neo4j

On Mon, Mar 11, 2013 at 12:48 AM, Ate Douma a...@douma.nu wrote:

 On 03/10/2013 11:59 PM, Matt Franklin wrote:

 On Sunday, March 10, 2013, wrote:

  Thanks for the insight Ate.

 Rene, I think we should take Ate's suggestion and send an email to 
 legal-discussion@ (please CC shindig-dev@).  If they say it is OK 
 than we continue the discussion about integrating the patch.



 Although the answer from Peter Neubauer / neotechnology is 
 accommodating on this matter and seems to indicate *they* might think 
 this is not a problem, reading the AGPL [1] license tells me something
differently.
 I definitely would like this contribution to be acceptable, but we 
 must be very sure we're not opening a can of worms here.



 I agree that legal should be consulted if we intent to ship a war or 
 other archive with any neo4j (or other agpl) licensed binaries included.

 I don't think we can do that anyway. AGPL is a variant of GPL, and 
 we're not allowed, by ASF policy, to distribute any GPL artifact.



 As a first mitigation step, why don't we make this a separate maven 
 module and only ship the source and non-inclusive jar?  It should not 
 be a problem to ship a jar and source that only references the neo4j 
 libs as runtime dependencies.

 That might be a possibility to investigate. As Chris noted in another 
 email, it might be doable as Camel seemingly also has a neo4j component.


I looked into it and Camel uses the Spring Neo4J library which is apache
licensed [1].

[1] http://www.springsource.org/spring-data/neo4j


 But also note: it will also depend on the type of reference such an 
 optional module uses. If it requires explicit Java imports and direct 
 usage of the neo4j APIs, this might qualifies as what is called in the 
 AGPL 'Corresponding Source'. Especially as neo4j and Shindig provide 
 and expect 'Remote Network Interaction' for which the AGPL is 
 especially created to enforce its license to downstream users. IMO 
 this can lead to a conflict with the AS2.0 license, to possibly not 
 even be allowed distribution under that license from within the ASF, 
 or not even its sources be checked into svn...

 But IANAL so indeed this should be run through legal-discuss@ first.

 [1] 
 http://www.gnu.org/licenses/**agpl-3.0.htmlhttp://www.gnu.org/license
 s/agpl-3.0.html







 On Mar 9, 2013, at 7:56 AM, René Peinl 
 rene.pe...@hof-university.de
 wrote:

  Dear Ate,
 thanks for your comments. I already thought about this and asked 
 the

 guys from neo technologies. Here is the answer from Peter Neubauer.


 in principle (IANAL) it is ok to have ALv2 licensed code binding to 
 GPL

 code. In runtime, the user will not be shielded from the GPL core, 
 which means the runtime will have GPL characteristics when you plug in
Neo4j.
 That is exactly the intent, and should be ok. The bindings-code is 
 development-time Apache license, regarding contributions and 
 copyright etc, so I think this should be ok.


 I'm not quite sure if that answers your question. I can further

 investigate if necessary.

 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ate Douma [mailto:a...@douma.nu]
 Gesendet: Freitag, 8. März 2013 14:18
 An: dev@shindig.apache.org
 Betreff: Re: Review Request: Alternative database backend based on 
 graph

 database neo4j


 Just from the peanut gallery, but neo4j is AGPL licensed.
 Normally any database backend access which is abstracted away 
 behind

 'plain'

 JDBC interfaces are allright to use, commercial versions or 
 otherwise

 licensed, because the end-user would have the option to choose 
 whatever
 (compatible) database they want to use.


 However with neo4j this seems different. Even with only optional 
 support

 for neo4j, the neo4j integration might require explicit neo4j (Java) 
 APIs and dependencies? I haven't reviewed the code for this, but if 
 it imports neo4j APIs then their AGPL license can be too invasive 
 and then possibly not acceptable for uses within our AL2.0 licensed
codebase.

 Or even if that could be allowed, I would make sure to check and 
 ask

 (legal-discuss@ etc.) if it would be acceptable from ASF policy POV.


 Regards, Ate

 On 03/07/2013 07:46 PM, Henry Saputra wrote:

 This is good news.

 One immediate comment is about the package name.
 Would it be possible to put it under org.apache.shindig rather 
 than the de.hofuniversity?

 This would make the contributions uniform like from other 
 companies and organizations.

 - Henry


 2013/3/6 René Peinl rene.pe...@hof-university.de

AW: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

Dear Apache legal advisors, dear Shindig developers,
as you can see from the discussion below, we have a possible license
conflict between AGPL and APL v2. 
We want to integrate code that uses neo4j, a graph database which is
licensed under AGPL, into Shindig. From my perspective it is not necessary
to include any neo4j binaries nor code, but I'm not sure how this affects
compilability. Maybe we can only use the REST API then and don't offer to
run neo4j in embedded mode.  
I'm not a lawyer nor a licensing specialist, so please advise on how to
proceed. Maybe we can find a workaround that ensures we are conforming to
the licensing terms and still get the new functionality into Shindig.
One suggestion that seems a good one was to check how Apache Camel deals
with this issue.
Regards and many thanks for clarification in advance
René

-Ursprüngliche Nachricht-
Von: Ate Douma [mailto:a...@douma.nu] 
Gesendet: Montag, 11. März 2013 08:49
An: dev@shindig.apache.org
Cc: Peter Neubauer
Betreff: Re: Review Request: Alternative database backend based on graph
database neo4j

On 03/10/2013 11:59 PM, Matt Franklin wrote:
 On Sunday, March 10, 2013, wrote:

 Thanks for the insight Ate.

 Rene, I think we should take Ate's suggestion and send an email to 
 legal-discussion@ (please CC shindig-dev@).  If they say it is OK 
 than we continue the discussion about integrating the patch.


Although the answer from Peter Neubauer / neotechnology is accommodating on
this matter and seems to indicate *they* might think this is not a problem,
reading the AGPL [1] license tells me something differently.
I definitely would like this contribution to be acceptable, but we must be
very sure we're not opening a can of worms here.


 I agree that legal should be consulted if we intent to ship a war or 
 other archive with any neo4j (or other agpl) licensed binaries included.
I don't think we can do that anyway. AGPL is a variant of GPL, and we're not
allowed, by ASF policy, to distribute any GPL artifact.


 As a first mitigation step, why don't we make this a separate maven 
 module and only ship the source and non-inclusive jar?  It should not 
 be a problem to ship a jar and source that only references the neo4j 
 libs as runtime dependencies.
That might be a possibility to investigate. As Chris noted in another email,
it might be doable as Camel seemingly also has a neo4j component.

But also note: it will also depend on the type of reference such an optional
module uses. If it requires explicit Java imports and direct usage of the
neo4j APIs, this might qualifies as what is called in the AGPL
'Corresponding Source'. 
Especially as neo4j and Shindig provide and expect 'Remote Network
Interaction' 
for which the AGPL is especially created to enforce its license to
downstream users. IMO this can lead to a conflict with the AS2.0 license, to
possibly not even be allowed distribution under that license from within the
ASF, or not even its sources be checked into svn...

But IANAL so indeed this should be run through legal-discuss@ first.

[1] http://www.gnu.org/licenses/agpl-3.0.html






 On Mar 9, 2013, at 7:56 AM, René Peinl rene.pe...@hof-university.de
 wrote:

 Dear Ate,
 thanks for your comments. I already thought about this and asked the
 guys from neo technologies. Here is the answer from Peter Neubauer.

 in principle (IANAL) it is ok to have ALv2 licensed code binding to 
 GPL
 code. In runtime, the user will not be shielded from the GPL core, 
 which means the runtime will have GPL characteristics when you plug in
Neo4j.
 That is exactly the intent, and should be ok. The bindings-code is 
 development-time Apache license, regarding contributions and 
 copyright etc, so I think this should be ok.

 I'm not quite sure if that answers your question. I can further
 investigate if necessary.
 Regards
 René

 -Ursprüngliche Nachricht-
 Von: Ate Douma [mailto:a...@douma.nu]
 Gesendet: Freitag, 8. März 2013 14:18
 An: dev@shindig.apache.org
 Betreff: Re: Review Request: Alternative database backend based on 
 graph
 database neo4j

 Just from the peanut gallery, but neo4j is AGPL licensed.
 Normally any database backend access which is abstracted away behind
 'plain'
 JDBC interfaces are allright to use, commercial versions or 
 otherwise
 licensed, because the end-user would have the option to choose 
 whatever
 (compatible) database they want to use.

 However with neo4j this seems different. Even with only optional 
 support
 for neo4j, the neo4j integration might require explicit neo4j (Java) 
 APIs and dependencies? I haven't reviewed the code for this, but if 
 it imports neo4j APIs then their AGPL license can be too invasive and 
 then possibly not acceptable for uses within our AL2.0 licensed codebase.
 Or even if that could be allowed, I would make sure to check and ask
 (legal-discuss@ etc.) if it would be acceptable from ASF policy POV.

 Regards, Ate

 On 03/07/2013 07:46 PM, Henry Saputra wrote

AW: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

Dear Ate,
thanks for your comments. I already thought about this and asked the guys from 
neo technologies. Here is the answer from Peter Neubauer.

in principle (IANAL) it is ok to have ALv2 licensed code binding to GPL code. 
In runtime, the user will not be shielded from the GPL core, which means the 
runtime will have GPL characteristics when you plug in Neo4j. That is exactly 
the intent, and should be ok. The bindings-code is development-time Apache 
license, regarding contributions and copyright etc, so I think this should be 
ok.

I'm not quite sure if that answers your question. I can further investigate if 
necessary.
Regards
René 

-Ursprüngliche Nachricht-
Von: Ate Douma [mailto:a...@douma.nu] 
Gesendet: Freitag, 8. März 2013 14:18
An: dev@shindig.apache.org
Betreff: Re: Review Request: Alternative database backend based on graph 
database neo4j

Just from the peanut gallery, but neo4j is AGPL licensed.
Normally any database backend access which is abstracted away behind 'plain' 
JDBC interfaces are allright to use, commercial versions or otherwise licensed, 
because the end-user would have the option to choose whatever (compatible) 
database they want to use.

However with neo4j this seems different. Even with only optional support for 
neo4j, the neo4j integration might require explicit neo4j (Java) APIs and 
dependencies? I haven't reviewed the code for this, but if it imports neo4j 
APIs then their AGPL license can be too invasive and then possibly not 
acceptable for uses within our AL2.0 licensed codebase.
Or even if that could be allowed, I would make sure to check and ask 
(legal-discuss@ etc.) if it would be acceptable from ASF policy POV.

Regards, Ate

On 03/07/2013 07:46 PM, Henry Saputra wrote:
 This is good news.

 One immediate comment is about the package name.
 Would it be possible to put it under org.apache.shindig rather than 
 the de.hofuniversity?

 This would make the contributions uniform like from other companies 
 and organizations.

 - Henry


 2013/3/6 René Peinl rene.pe...@hof-university.de


 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9773/
 ---

 Review request for shindig.


 Description
 ---

 Review for Shindig-1911
 Alternative database backend based on graph database neo4j Any 
 comments welcome. We are committed to further improve this.


 This addresses bug Shindig-1911.
  https://issues.apache.org/jira/browse/Shindig-1911


 Diffs
 -

/trunk/java/neo4j-backend/pom.xml PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/Constants.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/GraphAPIModule.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/GraphConfig.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/GuiceModule.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/db/neo4j/INeo4jConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/db/neo4j/Neo4jConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/db/neo4j/Neo4jHAConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/db/neo4j/Neo4jRelTypes.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/db/neo4j/Neo4jRestConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/ExtOrgPersonImpl.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/ExtOrganizationImpl.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/IExtOrgPerson.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/IExtOrganization.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherActivityEntry.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherActivityObject.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherAttributesMessage.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherListFieldList.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherMessage.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphb
 ackend/model/cypher/CypherMessageCollection.java

Re: Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/service/IDManagerTest.java
 PRE-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/util/NodeFilterTest.java
 PRE-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/util/NodeSorterTest.java
 PRE-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/util/PersonFilterTest.java
 PRE-CREATION 
  /trunk/pom.xml 1452786 

Diff: https://reviews.apache.org/r/9773/diff/


Testing
---


Thanks,

René Peinl

Review Request: Alternative database backend based on graph database neo4j

[René Peinl]

/NodeFilterTest.java
 PRE-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/util/NodeSorterTest.java
 PRE-CREATION 
  
/trunk/java/neo4j-backend/src/test/java/de/hofuniversity/iisys/graphbackend/util/PersonFilterTest.java
 PRE-CREATION 
  /trunk/pom.xml 1452786 

Diff: https://reviews.apache.org/r/9773/diff/


Testing
---


Thanks,

René Peinl

Re: Review Request: partial solution for Shindig issue 1899 (create friend relations)

[René Peinl]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9177/
---

(Updated Feb. 12, 2013, 8:49 a.m.)


Review request for shindig.


Changes
---

fixed the issues that Dan described


Description
---

see https://issues.apache.org/jira/browse/SHINDIG-1899


This addresses bug SHINDIG-1899.
https://issues.apache.org/jira/browse/SHINDIG-1899


Diffs (updated)
-

  
/trunk/java/samples/src/main/java/org/apache/shindig/social/opensocial/jpa/spi/JPASocialModule.java
 1437957 
  /trunk/java/social-api/pom.xml 1437957 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/core/spi/FriendServiceImpl.java
 PRE-CREATION 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/PersonHandler.java
 1437957 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/FriendService.java
 PRE-CREATION 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/sample/SampleModule.java
 1437957 
  
/trunk/java/social-api/src/test/java/org/apache/shindig/social/SocialApiTestsGuiceModule.java
 1437957 
  
/trunk/java/social-api/src/test/java/org/apache/shindig/social/opensocial/service/PersonHandlerTest.java
 1437957 

Diff: https://reviews.apache.org/r/9177/diff/


Testing
---


Thanks,

René Peinl

Re: Review Request: partial solution for Shindig issue 1899 (create friend relations)

[René Peinl]

 On Feb. 12, 2013, 1:49 a.m., Ryan Baxter wrote:
  Rene it looks like you close the issues Dan raised but it doesn't look they 
  were actually fixed in the code, do you plan on updating the patch?

I updated the patch in Jira, where I think it belongs. I forgot about the 
redundant data storing here in reviews and didn't update here. 
My research topic is systems integration and it seems that the Apache 
foundation has not yet heard about such a thing. Double logins, double patch 
submission. This really sucks.


- René


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9177/#review16455
---


On Feb. 12, 2013, 8:49 a.m., René Peinl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9177/
 ---
 
 (Updated Feb. 12, 2013, 8:49 a.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 see https://issues.apache.org/jira/browse/SHINDIG-1899
 
 
 This addresses bug SHINDIG-1899.
 https://issues.apache.org/jira/browse/SHINDIG-1899
 
 
 Diffs
 -
 
   
 /trunk/java/samples/src/main/java/org/apache/shindig/social/opensocial/jpa/spi/JPASocialModule.java
  1437957 
   /trunk/java/social-api/pom.xml 1437957 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/core/spi/FriendServiceImpl.java
  PRE-CREATION 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/PersonHandler.java
  1437957 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/FriendService.java
  PRE-CREATION 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/sample/SampleModule.java
  1437957 
   
 /trunk/java/social-api/src/test/java/org/apache/shindig/social/SocialApiTestsGuiceModule.java
  1437957 
   
 /trunk/java/social-api/src/test/java/org/apache/shindig/social/opensocial/service/PersonHandlerTest.java
  1437957 
 
 Diff: https://reviews.apache.org/r/9177/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 René Peinl
 

Review Request: partial solution for Shindig issue 1899 (create friend relations)

[René Peinl]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9177/
---

Review request for shindig.


Description
---

see https://issues.apache.org/jira/browse/SHINDIG-1899


Diffs
-

  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/PersonHandler.java
 1437957 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/FriendService.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/9177/diff/


Testing
---


Thanks,

René Peinl

Re: Review Request: partial solution for Shindig issue 1899 (create friend relations)

[René Peinl]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9177/
---

(Updated Jan. 31, 2013, 4:23 p.m.)


Review request for shindig.


Description
---

see https://issues.apache.org/jira/browse/SHINDIG-1899


This addresses bug SHINDIG-1899.
https://issues.apache.org/jira/browse/SHINDIG-1899


Diffs
-

  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/PersonHandler.java
 1437957 
  
/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/FriendService.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/9177/diff/


Testing
---


Thanks,

René Peinl

Re: Review Request: partial solution for Shindig issue 1899 (create friend relations)

[René Peinl]

 On Jan. 31, 2013, 3:11 p.m., Dan Dumont wrote:
  Please link the jira in the Bugs field of the review.  Just type the jira 
  name SHINDIG-.

done


- René


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9177/#review15934
---


On Jan. 31, 2013, 4:23 p.m., René Peinl wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9177/
 ---
 
 (Updated Jan. 31, 2013, 4:23 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 see https://issues.apache.org/jira/browse/SHINDIG-1899
 
 
 This addresses bug SHINDIG-1899.
 https://issues.apache.org/jira/browse/SHINDIG-1899
 
 
 Diffs
 -
 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/PersonHandler.java
  1437957 
   
 /trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/FriendService.java
  PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/9177/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 René Peinl
 

AW: Shindig neo4j backend

[René Peinl]

Hi Matthew,
the puzzle pieces start to fit together for me.
As you mention security tokens. This is one of the major problems we still
have with Shindig/Rave integration. It seems like Rave has a much more
evolved security architecture and Shindig is currently only evaluating the
tokens Rave is generating against some non-encrypted demo-tokens which fails
for obvious reasons.
Any hints on how to overcome this problem?
Regards
René

-Ursprüngliche Nachricht-
Von: Franklin, Matthew B. [mailto:mfrank...@mitre.org] 
Gesendet: Freitag, 13. Juli 2012 13:56
An: dev@shindig.apache.org
Cc: 'Florian Holzschuher'
Betreff: RE: Shindig neo4j backend



-Original Message-
From: René Peinl [mailto:rene.pe...@hof-university.de]
Sent: Friday, July 13, 2012 1:46 AM
To: dev@shindig.apache.org
Cc: 'Florian Holzschuher'
Subject: 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.

Rave's common data abstraction is built for data that needs to be accessed
from both Shindig  Rave.  To be clear, these are convenience classes and
you could absolutely use a pure Shindig implementation, so long as you are
careful to manage the properties yourself and put encryption keys where the
Rave instance can find them (for security token). 

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.

Rave offers a Spring/Guice bridge so that the components defined as Spring
beans can be bound to Guice injectors.  There is documentation on the Rave
website for how to override beans in the context so that your own
implementations could be used.

As for the database, I wouldn't restrict it completely to Relational for the
portal data.  You *could* use a Neo4j instance, but I don't really see the
value in storing that data in a graph...  I do see the value in storing
portal data in MongoDB as it is pretty much document oriented anyway.
However, Rave already has a relational DB implementation done in JPA, so it
is the shortest route.  I hope to work some on a MongoDb impl at the
Apache@OSCON Social  Widgets hackathon.


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.

I think having 3.0 code is OK so long as it is  not a breaking change for
2.5 compliance.  Other thoughts?


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

Shindig neo4j backend

[René Peinl]

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

AW: Shindig neo4j backend

[René Peinl]

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,

 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

AW: Shindig neo4j backend

[René Peinl]

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