On Fri, Jul 13, 2012 at 8:32 AM, Franklin, Matthew B. <mfrank...@mitre.org> wrote: >>-----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.
Just as an FYI, in a production environment Shindig would encrypt the security tokens, by default that is turned off. > >> >>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) >>>> >>>> >>>> >>>> >>>> >> >
