ActivityService SPI Implementation

["Ciancetta, Jesse E." <jc...@mitre.org>]

Hi,

I'm working on a persistent ActivityService implementation for Java Shindig and have a question regarding the parameters passed into the interface methods - how do we know which parameters we're supposed to use and which ones to ignore?

I'm looking at the JsonDbOpensocialService and ActivityServiceDb sample implementations, and it looks like in most of the interface methods the groupId and appId parameters aren't used for anything.

Is that only because these are samples and aren't intended to be complete?  Should I be checking to see if they're null or empty, and if not, using them in the queries to my backend store?

Thanks!

--Jesse

Re: ActivityService SPI Implementation

[Louis Ryan <lr...@google.com>]

Jesse,
Yes, its largely because the implementations are samples. For activities if
you take a look at the OpenSocial rest spec the API doesnt define how groups
are used so in this case the implementation in Shindig is up to spec.
However that doesnt mean that the spec is doing a good job in this area, you
can wasily imagine how you could use group to read activities generated /
received by a specific audience. Hence they were thrown into Shindig's SPI
in anticipation of this being specced out.

- Louis

On Wed, Sep 30, 2009 at 7:23 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:

> Hi,
>
> I'm working on a persistent ActivityService implementation for Java Shindig
> and have a question regarding the parameters passed into the interface
> methods - how do we know which parameters we're supposed to use and which
> ones to ignore?
>
> I'm looking at the JsonDbOpensocialService and ActivityServiceDb sample
> implementations, and it looks like in most of the interface methods the
> groupId and appId parameters aren't used for anything.
>
> Is that only because these are samples and aren't intended to be complete?
>  Should I be checking to see if they're null or empty, and if not, using
> them in the queries to my backend store?
>
> Thanks!
>
> --Jesse
>

Re: Can multiple social sites share a single deployment of shindig?

[Chris Chabot <ch...@google.com>]

Ok so the good news is that shindig is made to work with several container
configurations, if you look at the top of container.js you'll see that the
entire config is wrapped in this top level entry:
{"gadgets.container" : ["default"],
... lots of stuff ...
}

This means this is the default container config, but there could be entries
for other container keys too.

Now I could tell you the exact details of how this is done in the variant,
but I'm afraid I'm not sure how that's done in Java, my guess is that the
default JsonContainerConfig scans the container/*.js directory for files
called *.{js,json} and loads those, but as I mentioned, I'm mostly just
guessing here, you could probably find out by looking at
shindig/java/common/src/main/java/org/apache/shindig/config/JsonContainerConfig.java
and take it from there



On Fri, Oct 2, 2009 at 4:03 PM, Randy Hudson <hu...@us.ibm.com> wrote:

> Great!  But then I'm a little confused about shindig's config file:
> "container.js".  Is shindig the "container", or is it a "gadget server"
> for multiple containers.
>
> In container.js, there is one setting for "parentRelayUrl".  Couldn't that
> setting be different for each container?  Maybe the containers could pass
> that setting in as a param?
>
> Similarly, the containers need to know where the gadget server's relay URL
> is.  It seems "parentRelayUrl" is actually (or also) "gadgetRelayUrl", so
> is there a discovery mechanism for containers to fetch this (and possibly
> other) settings from shindig?
>
> Thanks,
> -Randy
>
>
>
> From:
> Chris Chabot <ch...@google.com>
> To:
> shindig-dev@incubator.apache.org
> Date:
> 10/02/2009 07:48 AM
> Subject:
> Re: Can multiple social sites share a single deployment of shindig?
>
>
>
> Hey Randy,
>
> Absolutely, in fact many deployments do actually use that already (Google
> being one example).
>
> The trick is to use the container param (which is part of the security
> token) and / or domain to know which data source the requests should be
> routed too.
>
> On Wed, Sep 30, 2009 at 5:07 PM, Randy Hudson <hu...@us.ibm.com> wrote:
>
> > I'm wondering about the intended/supported deployment topologies for
> > shindig.  Is it possible to have multiple sites (i.e. the
> > top-level/container page) hosted on multiple servers but sharing a
> common
> > deployment of shindig for serving the rendered gadgets?  Or is the
> > intended use that shindig is deployed along with each "social site"
> > requiring shindig's services.
> >
> > One reason I ask is that I see some config settings in shindig that
> refer
> > to properties of the consuming site.
> >
> > Thanks,
> > Randy Hudson
>
>

Re: Can multiple social sites share a single deployment of shindig?

[Randy Hudson <hu...@us.ibm.com>]

Great!  But then I'm a little confused about shindig's config file: 
"container.js".  Is shindig the "container", or is it a "gadget server" 
for multiple containers.

In container.js, there is one setting for "parentRelayUrl".  Couldn't that 
setting be different for each container?  Maybe the containers could pass 
that setting in as a param?

Similarly, the containers need to know where the gadget server's relay URL 
is.  It seems "parentRelayUrl" is actually (or also) "gadgetRelayUrl", so 
is there a discovery mechanism for containers to fetch this (and possibly 
other) settings from shindig?

Thanks,
-Randy



From:
Chris Chabot <ch...@google.com>
To:
shindig-dev@incubator.apache.org
Date:
10/02/2009 07:48 AM
Subject:
Re: Can multiple social sites share a single deployment of shindig?



Hey Randy,

Absolutely, in fact many deployments do actually use that already (Google
being one example).

The trick is to use the container param (which is part of the security
token) and / or domain to know which data source the requests should be
routed too.

On Wed, Sep 30, 2009 at 5:07 PM, Randy Hudson <hu...@us.ibm.com> wrote:

> I'm wondering about the intended/supported deployment topologies for
> shindig.  Is it possible to have multiple sites (i.e. the
> top-level/container page) hosted on multiple servers but sharing a 
common
> deployment of shindig for serving the rendered gadgets?  Or is the
> intended use that shindig is deployed along with each "social site"
> requiring shindig's services.
>
> One reason I ask is that I see some config settings in shindig that 
refer
> to properties of the consuming site.
>
> Thanks,
> Randy Hudson

Re: Can multiple social sites share a single deployment of shindig?

[Chris Chabot <ch...@google.com>]

Hey Randy,

Absolutely, in fact many deployments do actually use that already (Google
being one example).

The trick is to use the container param (which is part of the security
token) and / or domain to know which data source the requests should be
routed too.

On Wed, Sep 30, 2009 at 5:07 PM, Randy Hudson <hu...@us.ibm.com> wrote:

> I'm wondering about the intended/supported deployment topologies for
> shindig.  Is it possible to have multiple sites (i.e. the
> top-level/container page) hosted on multiple servers but sharing a common
> deployment of shindig for serving the rendered gadgets?  Or is the
> intended use that shindig is deployed along with each "social site"
> requiring shindig's services.
>
> One reason I ask is that I see some config settings in shindig that refer
> to properties of the consuming site.
>
> Thanks,
> Randy Hudson

Can multiple social sites share a single deployment of shindig?

[Randy Hudson <hu...@us.ibm.com>]

I'm wondering about the intended/supported deployment topologies for 
shindig.  Is it possible to have multiple sites (i.e. the 
top-level/container page) hosted on multiple servers but sharing a common 
deployment of shindig for serving the rendered gadgets?  Or is the 
intended use that shindig is deployed along with each "social site" 
requiring shindig's services.

One reason I ask is that I see some config settings in shindig that refer 
to properties of the consuming site.

Thanks,
Randy Hudson