shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: AW: Shindig neo4j backend
Date Fri, 13 Jul 2012 11:56:51 GMT


>-----Original Message-----
>From: Stanton Sievers [mailto:ssievers@us.ibm.com]
>Sent: Friday, July 13, 2012 6:50 AM
>To: dev@shindig.apache.org
>Cc: Florian Holzschuher
>Subject: Re: AW: Shindig neo4j backend
>
>Hi René,
>
>If you'd like to contribute code back to Shindig, the first step is to
>open a JIRA [1].  The second step is to create an account on the Review
>Board instance [2] and post a review with your patch.  Within your review
>you can add the "shindig" group to send a notification of your review our
>to this list.

This is the same process for Rave just s/shindig/rave

>
>If you're just looking for some feedback on ideas that are easier to
>express via a source code patch, you can skip right to the Review Board
>site and create the JIRA at a later time.
>
>Thanks,
>-Stanton
>
>[1]  https://issues.apache.org/jira/browse/SHINDIG
>[2] https://reviews.apache.org/
>
>
>
>From:   René Peinl <rene.peinl@hof-university.de>
>To:     <dev@shindig.apache.org>,
>Cc:     "Florian Holzschuher" <fholzschuher2@hof-university.de>
>Date:   07/13/2012 01:46
>Subject:        AW: Shindig neo4j backend
>
>
>
>Hi,
>thanks for all the good suggestions.
>One last question for the moment: how exactly do we contribute our code?
>Should we open a Jira issue and attach the sources?
>Maybe there are new suggestions, once you've seen our code.
>Regards
>René
>
>-----Ursprüngliche Nachricht-----
>Von: Henry Saputra [mailto:henry.saputra@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.peinl@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.peinl@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)
>>
>>
>>
>>
>>
>
>

Mime
View raw message