shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stanton Sievers" <>
Subject Re: AW: Shindig neo4j backend
Date Fri, 13 Jul 2012 12:26:11 GMT
Hi René,

Shindig doesn't use encrypted tokens by default.  I can't speak for what 
Rave is doing by default, but I can point you to some more information 
about Security Tokens in Shindig [1].  This documentation is not complete 
but should help as a starting point.  Any questions about the materials 
there can be directed back to the dev list or as comments on the wiki page 
(which I follow).



From:   René Peinl <>
To:     <>, 
Cc:     "'Florian Holzschuher'" <>
Date:   07/13/2012 08:12
Subject:        AW: Shindig neo4j backend

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 
for obvious reasons.
Any hints on how to overcome this problem?

-----Ursprüngliche Nachricht-----
Von: Franklin, Matthew B. [] 
Gesendet: Freitag, 13. Juli 2012 13:56
Cc: 'Florian Holzschuher'
Betreff: RE: Shindig neo4j backend

>-----Original Message-----
>From: René Peinl []
>Sent: Friday, July 13, 2012 1:46 AM
>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 
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 
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 
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 
>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?

>-----Ursprüngliche Nachricht-----
>Von: Ryan Baxter []
>Gesendet: Freitag, 13. Juli 2012 03:28
>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
>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 :)
>On Thu, Jul 12, 2012 at 11:25 AM, 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 
>> 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
>> 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 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
>> 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 
>> support on the data layer, which is currently not 
>> given in Shindig 2.5 beta2 
>> (, 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 
>> 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:
>> Requirements for OpenSocial Intranet Portal
>> Presentation layer
>> ·         Portal entry page with admin predefined gadgets, customizable
>> user
>> (mostly existing in Rave 0.12)
>> ·         Gadget catalog (existing in Rave 0.12)
>> ·         User profile page with photo, name and other attributes. 
>> 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
>> and search)
>> (not present in Rave 0.12 yet)
>> ·         Ability to add friends/following people to "friends network"
>> on profile page)
>> (not present in Rave 0.12 yet)
>> ·         Suggestion list for new friends based on common friends,
>> interests, etc.
>> (not present in Rave 0.12 yet)
>> ·         Ability to set a status message
>> (basic functionality available in Rave 0.12)
>> ·         Ability to send a personal message to a friend
>> (not present in Rave 0.12 yet, maybe possible with one of the 
>> gadgets)
>> Logic layer
>> ·         Gadget Rendering API
>> (existing in Shindig 2.5 beta2)
>> ·         Authentication against external identity and access 
>> system (IAM) using OAuth 2.0 and SAML.
>> (some references state that Apache Shiro is able to do that, but we 
>> haven't seen the code implementing it)
>> ·         Exposing social media data like friends, activities, . as
>> Web services
>> (available in Shindig 2.5 beta2)
>> ·         Exposing extended social media data like friend of a friend 
>> portal gadgets as RESTful Web service (draft implementation available 
>> at iisys)
>> Data layer
>> ·         Full support for data storage and retrieval 
>> data object layer
>> (draft implementation available at iisys, but not with JPA support)
>> ·         Storing/retrieving social media data like friends, 
>> ratings, bookmarks, tags, . in/from a graph database like neo4j 
>> (draft implementation available at iisys, it has to be discussed, 
>> whether it would be better to use SpringData JPA abstraction instead 
>> of direct neo4j access)
>> ·         Integrating Rave and Shindig person data
>> (not clear why Rave is having its own Person class which seems like a 
>> subset of Shindigs PersonDB)
>> ·         Keeping Rave User and PageUser data consistent with IAM 
>> ·         Storing Rave authorization data (gadget permissions, user
>> preferences, .)  in neo4j
>> (not available yet)
>> ·         Storing Rave general user data in neo4j.
>> (not available yet)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message