>-----Original Message----- >From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >Sent: Friday, July 13, 2012 8:26 AM >To: dev@shindig.apache.org >Cc: 'Florian Holzschuher' >Subject: Re: AW: Shindig neo4j backend > >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).
Right. Rave does enable security tokens by default using the Shindig infrastructure. > >Thanks, >-Stanton > >[1] https://cwiki.apache.org/confluence/display/SHINDIG/Security+Tokens > > > >From: René Peinl <rene.pe...@hof-university.de> >To: <dev@shindig.apache.org>, >Cc: "'Florian Holzschuher'" <fholzschuh...@hof-university.de> >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 >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 spec your contributions will be welcomed there >>as well, especially if you provide an implementation for it :) >> >>-Ryan >> >>On Thu, Jul 12, 2012 at 11:25 AM, René Peinl >><rene.pe...@hof-university.de> >>wrote: >>> Dear Shindig developers, >>> >>> I'm working together with my colleague Florian on a systems >>> integration research project that brings together a DMS, a groupware >>> system, an ERP system in an Intranet scenario and adds social media >>> capabilities under the hood of a central lightweight portal (see >>> requirements overview at the end of the email). >>> >>> >>> >>> For the portal, we are planning to use Shindig as the central >>> component and maybe Rave as a basis for the presentation layer. >>> Since social media data is inherently graph-oriented, we are planning >>> to use neo4j as the storage engine for Shindig (and maybe Rave as >well). >>> Florian has already implemented a draft of this neo4j storage layer >>> which works well for some sample data that we have generated (if >>> anyone is interested we can provide the sample data and the generator >>> for it), but due to simplicity reasons and to avoid additional >>> conversion operations in between the storage layer is currently not >>> using JPA, but directly writing the objects to the database >>> (replacing >>e.g. both PersonImpl and PersonDB). >>> >>> >>> >>> Lately, we have discovered Rave and found out that despite its close >>> integration with Shindig it uses its own database abstraction and >>> partly competing implementations for classes that are already present >>> in >>Shindig. >>> For example there is rave.portal.model.Person which uses JPA to store >>> a (incomplete compared to OpenSocial 2.0 specs) person object in the >>> database and there is shindig.social.opensocial.jpa.PersonDB which >>> does the same, but seems like a complete implementation of the fields >>> defined in OpenSocial 2.0. >>> >>> >>> >>> My goal is to better understand the decisions behind the current >>> implementation of both Shindig and Rave (I've posted a similar >>> question on the Rave mailing list) in order to find a solution for >>> our project that lets the Apache community benefit as much as >>> possible from our efforts, without burdening our project too much >>> with >>non-project-specific requirements. >>> >>> >>> >>> The options we have (from my perspective) are as follows >>> >>> 1) Kind of forking the Shindig project and using our own neo4j >>backend >>> and not using Rave >>> >>> 2) Going one step further and integrating Rave with our own neo4j >>> Shindig backend and eliminate the duplicate classes >>> >>> 3) Trying to use SpringData JPA abstraction layer for neo4j and >>> providing some extended functionality in own classes (e.g. a >>> friend-of-a-friend query could be implemented with relational DBs as >>> well, but doesn't make too much sense due to performance reasons) and >>> hoping that the Rave and Shindig community are helping us to >>> eliminate the duplicate implementations on JPA level. >>> >>> >>> >>> All options have their pros and cons and I'd really like to hear your >>> opinion on that. If you have the feeling that our project idea is >>> very specific and you don't see any use for the results in your >>> scenarios than it may be better for both sides if we are building a >>> fork. On the other hand, if you think that the principle idea behind >>> our project would be beneficial for your scenarios as well, we would >>> be happy to work >>together on that. >>> We need e.g. some of the missing OpenSocial 2.0 features like full >>> activitystrea.ms support on the data layer, which is currently not >>> given in Shindig 2.5 beta2 >>> (https://issues.apache.org/jira/browse/SHINDIG-1536), but we do not >>> want >>to interfere with your roadmap and release plans. >>> We also found several common scenarios that e.g. MS SharePoint is >>> supporting, but that are not feasible with OpenSocial 2.0 >>> specification (mainly due to its focus on Internet scenarios). >>> Examples are: User has checked-out a document in a DMS. For this kind >>> of check-out operation, there is no post verb in the activitystrea.ms >>> standard. We would be happy to bring these finding into the ongoing >>> discussion about future Open Social versions. >>> >>> >>> >>> Summed up, we wanted to know how we could best cooperate with the >>> existing Shindig (and Rave) community in order to quickly achieve our >>> goals and let the Apache community benefit the most from our efforts. >>> >>> Any suggestions? >>> >>> Regards >>> >>> René >>> >>> >>> >>> >>> >>> ----------------------------------------------------------- >>> >>> Prof. Dr. René Peinl >>> >>> Teaching area: architecture of Web applications >>> >>> University of applied Sciences Hof >>> >>> Alfons-Goppel-Platz 1, 95028 Hof, Bavaria, Germany >>> >>> Tel: +49-9281-409-4820 >>> >>> Email: rene.pe...@hof-university.de >>> >>> >>> >>> >>> >>> >>> >>> Requirements for OpenSocial Intranet Portal >>> >>> >>> >>> >>> Presentation layer >>> >>> >>> · Portal entry page with admin predefined gadgets, customizable >by >>> user >>> (mostly existing in Rave 0.12) >>> >>> · Gadget catalog (existing in Rave 0.12) >>> >>> · User profile page with photo, name and other attributes. >Admin >>> customizable. All open social fields should be available for display. >>> Gadgets can be used to show additional data like activity stream, >>> friends network, bookmarks/tags, . (basic functionality available in >>> Rave 0.12 /portal/app/person) >>> >>> · User directory with overview of existing users (including >paging >>> and search) >>> (not present in Rave 0.12 yet) >>> >>> · Ability to add friends/following people to "friends network" >>(e.g. >>> on profile page) >>> (not present in Rave 0.12 yet) >>> >>> · Suggestion list for new friends based on common friends, >>> interests, etc. >>> (not present in Rave 0.12 yet) >>> >>> · Ability to set a status message >>> (basic functionality available in Rave 0.12) >>> >>> · Ability to send a personal message to a friend >>> (not present in Rave 0.12 yet, maybe possible with one of the >>> gadgets) >>> >>> >>> >>> >>> Logic layer >>> >>> >>> · Gadget Rendering API >>> (existing in Shindig 2.5 beta2) >>> >>> · Authentication against external identity and access >management >>> system (IAM) using OAuth 2.0 and SAML. >>> (some references state that Apache Shiro is able to do that, but we >>> haven't seen the code implementing it) >>> >>> · Exposing social media data like friends, activities, . as >>RESTful >>> Web services >>> (available in Shindig 2.5 beta2) >>> >>> · Exposing extended social media data like friend of a friend >to >>> portal gadgets as RESTful Web service (draft implementation available >>> at iisys) >>> >>> >>> >>> >>> Data layer >>> >>> >>> · Full support for activitystrea.ms data storage and retrieval >at >>> data object layer >>> (draft implementation available at iisys, but not with JPA support) >>> >>> · Storing/retrieving social media data like friends, >activities, >>> ratings, bookmarks, tags, . in/from a graph database like neo4j >>> (draft implementation available at iisys, it has to be discussed, >>> whether it would be better to use SpringData JPA abstraction instead >>> of direct neo4j access) >>> >>> · Integrating Rave and Shindig person data >>> (not clear why Rave is having its own Person class which seems like a >>> subset of Shindigs PersonDB) >>> >>> · Keeping Rave User and PageUser data consistent with IAM >system >>> >>> · Storing Rave authorization data (gadget permissions, user >>> preferences, .) in neo4j >>> (not available yet) >>> >>> · Storing Rave general user data in neo4j. >>> (not available yet) >>> >>> >>> >>> >>> >
