shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: Shindig neo4j backend
Date Fri, 13 Jul 2012 05:16:53 GMT
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