shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Baxter <>
Subject Re: Shindig neo4j backend
Date Fri, 13 Jul 2012 12:35:12 GMT
On Friday, July 13, 2012, René Peinl wrote:

> 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.
> 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.
> 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 the confusion might arise because in the middle of our Shindig 3.0
release we reversioned 3.0 to 2.5 so the shindig version and OpenSocial
spec version match.  Because of the version change it is possible that
jiras marked as fixed in 3.0 are in our 2.5 release.

> Regards
> René
> -----Ursprüngliche Nachricht-----
> Von: Ryan Baxter [ <javascript:;>]
> Gesendet: Freitag, 13. Juli 2012 03:28
> An: <javascript:;>
> 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 <
> >
> 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 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

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