You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Christian Schalk <cs...@google.com> on 2008/04/03 01:50:23 UTC
Working on data integration guide for Shindig...
Hello shindig-dev,
It seems like a lot of the questions on shindig-dev are around how to wire
the OpenSocal API to a real backend. Given that, I'm in the process of
putting together a guide on how to attach your local version of Shindig to a
native datasource.
Here's a draft set of items that I'm planning to cover in the guide:
Basics
1. Quick review on how to install Shindig on your server.
- Testing some simple (non-OpenSocial) Gadgets on your server.
2. Testing an OpenSocial app within your Shindig environment
- Trying out the SampleContainer.
- Trying out some other simple OpenSocial apps with the
SampleContainer
- Playing around with simple XML based state data within the
SampleContainer
Intermediate-Advanced
1. State Data access concepts
- Reviewing concepts on how to access data
- The all Java approach - implementing interfaces
- The RPC approach - creating http based response
mechanisms
2. Building your own data access using either
- Java approach
- Getting familiar with the classes and interfaces in
org.apache.shindig.social.*.
- Implement the provided interfaces to access custom data.
- Language neutral RPC approach
- How to build your own http mechanism in PHP to serve
social data
Let me know if you any suggestions or additions, and we'll continue to flesh
this out and publish it.
Thanks,
-Chris
--
Chris Schalk, Google Developer Advocate
Re: Working on data integration guide for Shindig...
Posted by David Primmer <da...@gmail.com>.
I may be not as familiar with the API's already available, but as part
of the API server project, I'm hoping to solve this with a recently
developed way of connecting a native data source backend to the API
server. Abdera has the concept of a CollectionAdapter, which is an
object container that has a CRUD HTTP interface. It leaves to the
developer to choose a backend object mapping system -- the adapter
type. These adapters have the ability to use many different kinds of
data sources as their backing store.
>From the perspective of the 3 APIs in the spec. It will be fairly
straightforward to connect to a native data source. In the typical
case of a database that supports JDBC, an Ibatis XML field mapping
file is filled out and the work is done. No coding.
I don't know if this is the data that you're concerned with here or if
it is something else.
davep
On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cs...@google.com> wrote:
> Hello shindig-dev,
>
> It seems like a lot of the questions on shindig-dev are around how to wire
> the OpenSocal API to a real backend. Given that, I'm in the process of
> putting together a guide on how to attach your local version of Shindig to a
> native datasource.
>
> Here's a draft set of items that I'm planning to cover in the guide:
>
> Basics
>
>
> 1. Quick review on how to install Shindig on your server.
> - Testing some simple (non-OpenSocial) Gadgets on your server.
> 2. Testing an OpenSocial app within your Shindig environment
> - Trying out the SampleContainer.
> - Trying out some other simple OpenSocial apps with the
> SampleContainer
> - Playing around with simple XML based state data within the
> SampleContainer
>
>
> Intermediate-Advanced
>
>
> 1. State Data access concepts
> - Reviewing concepts on how to access data
> - The all Java approach - implementing interfaces
> - The RPC approach - creating http based response
> mechanisms
> 2. Building your own data access using either
> - Java approach
> - Getting familiar with the classes and interfaces in
> org.apache.shindig.social.*.
> - Implement the provided interfaces to access custom data.
> - Language neutral RPC approach
> - How to build your own http mechanism in PHP to serve
> social data
>
>
> Let me know if you any suggestions or additions, and we'll continue to flesh
> this out and publish it.
>
> Thanks,
> -Chris
>
> --
> Chris Schalk, Google Developer Advocate
>
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Thu, Apr 3, 2008 at 1:57 PM, Alejandro Rivero <al...@gmail.com>
wrote:
> > - The RPC approach - creating http based response
> > mechanisms
>
> Hmm, just to clarify:
>
> Is the "RPC approach" something standard to the shindig codebase, even
> eventually related to RpcServlet.java?. Or do you mean, simply, things
> as
Somewhat related. RpcServlet.java should probably be renamed to something
like "MetadataServlet" to better reflect what it's actually used for. The
idea is similar, though.
>
> =============
>
> fetchStateDocument("people/"+clavePersona+"/@friends").getDocumentElement();
> NodeList friendNodes= (NodeList)
> xpath.evaluate("/respuesta/people/person/authenticator", document
> , XPathConstants.NODESET);
> PersonFriendId= new ArrayList<String>();
> for (int j = 0; j < friendNodes.getLength(); j++) {
> String friendId = friendNodes.item(j).getTextContent();
> if (friendId != null && friendId.trim().length() != 0) {
> PersonFriendId.add(friendId.trim());
> ===============
>
> If the latter, I can provide some examples too, with a couple of hooks
> via python into a BOINC (seti@home like) database; it could be of some
> use in your guide.
>
> If the former, please do!! I do not understand yet the laberinth of
> RPC is gadgets/opensocial.
>
>
> Alejandro
>
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Alejandro Rivero <al...@gmail.com>.
> - The RPC approach - creating http based response
> mechanisms
Hmm, just to clarify:
Is the "RPC approach" something standard to the shindig codebase, even
eventually related to RpcServlet.java?. Or do you mean, simply, things
as
=============
fetchStateDocument("people/"+clavePersona+"/@friends").getDocumentElement();
NodeList friendNodes= (NodeList)
xpath.evaluate("/respuesta/people/person/authenticator", document
, XPathConstants.NODESET);
PersonFriendId= new ArrayList<String>();
for (int j = 0; j < friendNodes.getLength(); j++) {
String friendId = friendNodes.item(j).getTextContent();
if (friendId != null && friendId.trim().length() != 0) {
PersonFriendId.add(friendId.trim());
===============
If the latter, I can provide some examples too, with a couple of hooks
via python into a BOINC (seti@home like) database; it could be of some
use in your guide.
If the former, please do!! I do not understand yet the laberinth of
RPC is gadgets/opensocial.
Alejandro
Re: Working on data integration guide for Shindig...
Posted by Alejandro Rivero <al...@gmail.com>.
Hi.
I think the Basics are well covered in the Readme and source code; but
I'd really enjoy more doc on the Intermediate-Advanced part.
Particularly the RPC mecanism is obscure, because it does not appear
anywhere in the empirical learning path: from the SampleContainer the
natural jump is towards the BasicServices of the opensocial part, and
the uses of the RPC are not seen.
In fact for http/xml requests beyond the static BasicServices, we
could provide some extra example, along the lines of the
samplecontainer too.
Alejandro
2008/4/3, Christian Schalk <cs...@google.com>:
> Hello shindig-dev,
>
> It seems like a lot of the questions on shindig-dev are around how to wire
> the OpenSocal API to a real backend. Given that, I'm in the process of
> putting together a guide on how to attach your local version of Shindig to a
> native datasource.
>
> Here's a draft set of items that I'm planning to cover in the guide:
>
> Basics
>
>
> 1. Quick review on how to install Shindig on your server.
> - Testing some simple (non-OpenSocial) Gadgets on your server.
> 2. Testing an OpenSocial app within your Shindig environment
> - Trying out the SampleContainer.
> - Trying out some other simple OpenSocial apps with the
> SampleContainer
> - Playing around with simple XML based state data within the
> SampleContainer
>
>
> Intermediate-Advanced
>
>
> 1. State Data access concepts
> - Reviewing concepts on how to access data
> - The all Java approach - implementing interfaces
> - The RPC approach - creating http based response
> mechanisms
> 2. Building your own data access using either
> - Java approach
> - Getting familiar with the classes and interfaces in
> org.apache.shindig.social.*.
> - Implement the provided interfaces to access custom data.
> - Language neutral RPC approach
> - How to build your own http mechanism in PHP to serve
> social data
>
>
> Let me know if you any suggestions or additions, and we'll continue to flesh
> this out and publish it.
>
> Thanks,
> -Chris
>
>
> --
> Chris Schalk, Google Developer Advocate
>
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Thu, Apr 3, 2008 at 12:21 AM, Santiago Gala <sa...@gmail.com>
wrote:
>
> El mié, 02-04-2008 a las 22:44 -0700, Kevin Brown escribió:
> > On Wed, Apr 2, 2008 at 9:20 PM, Raymond Auge <ra...@liferay.com> wrote:
> >
> > > The shindig plugin we developed works as a fire and forget app in all
> > > the app server/servlet containers/RDBMS combinations that we support
> > > (which is extensive, literally hundreds of combinations).
> > >
> > > What we're missing is that "injectable" datasource backend.
> > >
> > > Right now I'm flat out replacing the implementation of
> > >
> > > org.apache.shindig.social.opensocial.OpenSocialDataHandler
> > >
> > > overriding the implementations of the Basic*Services.
> > >
> > > But that's not a very nice way of working with it. At the very least
> we
> > > need some way to wire in an implementation. This way you could have X
> > > backends bundled to handle the different possible scenarios, direct
> > > JDBC, DAO Service Tier, RPC implementation, etc, while still allowing
> > > for custom implementations.
> > >
> > > In our case, we're plugging in directly to our generated DAO service
> > > tier, so as to leverage existing caching infrastructure, cluster
> > > support, etc..., which means we'd want to implement the backend as a
> > > custom code anyway.
> > >
> > > The question is "which is the most accepted way of building out these
> > > plug-able backend implementations?"
> > >
> > > You can go anywhere from
> > > - classNames as servlet init-params in the web.xml file
> > > - classpath properties files specifying implementation classes
> > > ... all the way to ...
> > > - a Dependency Injection container like Spring...
> >
>
> What about a URL mapping and json as data exchange language? This is
> what CouchDB uses for DB mapping ;-)
>
> >
> > The DI wiring is already started (as of about 5pm today), using Guice.
> > Spring or other frameworks can be layered on top of this as appropriate.
> >
> > Again, though, this only satisfies the case of sites that are already
> Java
> > based.
>
> Yeah, people that got abducted into J2EE can't see other languages than
> java. I was there but I'm slowly recovering :)
>
> I hope that shindig will be kept as simple as possible and do data
> integration using Rest techniques or similar loose coupling.
>
> BTW, has anyone considered the Thrift podling starting recently at the
> ASF for the RPC mechanisms? I'm not really sure how would it fit.
It looks like it's just a proposal right now -- if it does indeed migrate
from facebook to apache I think it's a logical choice for us. It seems to be
based largely on a format virtually identical to the protocol buffer
specification that has been discussed in numerous google published white
papers (primarily the sawzall paper), so I'm sure it'll have a natural feel,
and it's not that far removed from what we're trying to do with our shindig
deployment at Google anyway.
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Santiago Gala <sa...@gmail.com>.
El mié, 02-04-2008 a las 22:44 -0700, Kevin Brown escribió:
> On Wed, Apr 2, 2008 at 9:20 PM, Raymond Auge <ra...@liferay.com> wrote:
>
> > The shindig plugin we developed works as a fire and forget app in all
> > the app server/servlet containers/RDBMS combinations that we support
> > (which is extensive, literally hundreds of combinations).
> >
> > What we're missing is that "injectable" datasource backend.
> >
> > Right now I'm flat out replacing the implementation of
> >
> > org.apache.shindig.social.opensocial.OpenSocialDataHandler
> >
> > overriding the implementations of the Basic*Services.
> >
> > But that's not a very nice way of working with it. At the very least we
> > need some way to wire in an implementation. This way you could have X
> > backends bundled to handle the different possible scenarios, direct
> > JDBC, DAO Service Tier, RPC implementation, etc, while still allowing
> > for custom implementations.
> >
> > In our case, we're plugging in directly to our generated DAO service
> > tier, so as to leverage existing caching infrastructure, cluster
> > support, etc..., which means we'd want to implement the backend as a
> > custom code anyway.
> >
> > The question is "which is the most accepted way of building out these
> > plug-able backend implementations?"
> >
> > You can go anywhere from
> > - classNames as servlet init-params in the web.xml file
> > - classpath properties files specifying implementation classes
> > ... all the way to ...
> > - a Dependency Injection container like Spring...
>
What about a URL mapping and json as data exchange language? This is
what CouchDB uses for DB mapping ;-)
>
> The DI wiring is already started (as of about 5pm today), using Guice.
> Spring or other frameworks can be layered on top of this as appropriate.
>
> Again, though, this only satisfies the case of sites that are already Java
> based.
Yeah, people that got abducted into J2EE can't see other languages than
java. I was there but I'm slowly recovering :)
I hope that shindig will be kept as simple as possible and do data
integration using Rest techniques or similar loose coupling.
BTW, has anyone considered the Thrift podling starting recently at the
ASF for the RPC mechanisms? I'm not really sure how would it fit.
Regards
--
Santiago Gala
http://memojo.com/~sgala/blog/
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 9:20 PM, Raymond Auge <ra...@liferay.com> wrote:
> The shindig plugin we developed works as a fire and forget app in all
> the app server/servlet containers/RDBMS combinations that we support
> (which is extensive, literally hundreds of combinations).
>
> What we're missing is that "injectable" datasource backend.
>
> Right now I'm flat out replacing the implementation of
>
> org.apache.shindig.social.opensocial.OpenSocialDataHandler
>
> overriding the implementations of the Basic*Services.
>
> But that's not a very nice way of working with it. At the very least we
> need some way to wire in an implementation. This way you could have X
> backends bundled to handle the different possible scenarios, direct
> JDBC, DAO Service Tier, RPC implementation, etc, while still allowing
> for custom implementations.
>
> In our case, we're plugging in directly to our generated DAO service
> tier, so as to leverage existing caching infrastructure, cluster
> support, etc..., which means we'd want to implement the backend as a
> custom code anyway.
>
> The question is "which is the most accepted way of building out these
> plug-able backend implementations?"
>
> You can go anywhere from
> - classNames as servlet init-params in the web.xml file
> - classpath properties files specifying implementation classes
> ... all the way to ...
> - a Dependency Injection container like Spring...
The DI wiring is already started (as of about 5pm today), using Guice.
Spring or other frameworks can be layered on top of this as appropriate.
Again, though, this only satisfies the case of sites that are already Java
based.
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Sat, Apr 5, 2008 at 10:22 AM, Ian Boston <ia...@googlemail.com>
wrote:
> I would like to be taking the shindig jar from repo2.apache.org/maven2
> and adding it to my own webapp, pulling the transitive deps through
> maven.
>
> Then adding my own jar, with some Guice modules to reconfigure the
> services and a custom web.xml to add those modules in.
>
> Ideally I dont want to have to open up the shindig jar and change
> anything inside it.
>
> This will fit in with our build and deployment, which at most of the
> sites in production is automated.
>
> but.... thats just one view of one user of Shindig, certainly not the
> only opinion.
>
> From what I have read and seen so far, I think that that approach fits in
> ?
Yes, as I said, this is essentially what we're doing at Google. I expect
that it'll be the preferred approach for most people running Java already,
whereas the war approach might be more suitable for containers that just
want to do some minor configuration changes.
>
> Ian
>
> On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> > On Fri, Apr 4, 2008 at 12:58 PM, Brian McCallister <br...@skife.org>
> wrote:
> >
> > > What is the planned deployment story for java-shindig? Do we want
> people
> > > to
> > > be able to take the war, drop it in a servlet container sprinkled
> with
> > > config magic to wire up their interfaces, and be done? Alternately,
> do
> > > they
> > > need to open up the war and rejigger it around?
> >
> >
> >
> > Right now we're producing both a war and a jar. At google we're using
> the
> > jar and wiring up some customized RemoteContentFetchers and a
> > GadgetTokenDecoder. Other people might want the war.
> >
> > The war is probably the best option for the black box solution. There
> are
> > definitely still some rough edges here, though, like providing a
> startup
> > script.
> >
> >
> >
> > >
> > > -Brian
> > >
> > > On Fri, Apr 4, 2008 at 7:06 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> > >
> > > > I think the patch I send a few hours back was missing some things,
> here
> > > it
> > > > is again (and working). Sorry if that wasted your time..... please
> > > ignore if
> > > > you have already done it.
> > > >
> > > >
> > > > Ian
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 4 Apr 2008, at 11:16, Cassie wrote:
> > > >
> > > > > Ian - your patch didn't come through.
> > > > >
> > > > > I am working on this as we speak and hope to have something
> checked in
> > > > > in just a couple hours (before my flight to london). If your
> patch
> > > > > works Ian - I'll gladly use it!
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
> > --
> >
> > ~Kevin
> >
>
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ia...@googlemail.com>.
I would like to be taking the shindig jar from repo2.apache.org/maven2
and adding it to my own webapp, pulling the transitive deps through
maven.
Then adding my own jar, with some Guice modules to reconfigure the
services and a custom web.xml to add those modules in.
Ideally I dont want to have to open up the shindig jar and change
anything inside it.
This will fit in with our build and deployment, which at most of the
sites in production is automated.
but.... thats just one view of one user of Shindig, certainly not the
only opinion.
>From what I have read and seen so far, I think that that approach fits in ?
Ian
On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> On Fri, Apr 4, 2008 at 12:58 PM, Brian McCallister <br...@skife.org> wrote:
>
> > What is the planned deployment story for java-shindig? Do we want people
> > to
> > be able to take the war, drop it in a servlet container sprinkled with
> > config magic to wire up their interfaces, and be done? Alternately, do
> > they
> > need to open up the war and rejigger it around?
>
>
>
> Right now we're producing both a war and a jar. At google we're using the
> jar and wiring up some customized RemoteContentFetchers and a
> GadgetTokenDecoder. Other people might want the war.
>
> The war is probably the best option for the black box solution. There are
> definitely still some rough edges here, though, like providing a startup
> script.
>
>
>
> >
> > -Brian
> >
> > On Fri, Apr 4, 2008 at 7:06 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> >
> > > I think the patch I send a few hours back was missing some things, here
> > it
> > > is again (and working). Sorry if that wasted your time..... please
> > ignore if
> > > you have already done it.
> > >
> > >
> > > Ian
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 4 Apr 2008, at 11:16, Cassie wrote:
> > >
> > > > Ian - your patch didn't come through.
> > > >
> > > > I am working on this as we speak and hope to have something checked in
> > > > in just a couple hours (before my flight to london). If your patch
> > > > works Ian - I'll gladly use it!
> > > >
> > > > - Cassie
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
> --
>
> ~Kevin
>
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Fri, Apr 4, 2008 at 12:58 PM, Brian McCallister <br...@skife.org> wrote:
> What is the planned deployment story for java-shindig? Do we want people
> to
> be able to take the war, drop it in a servlet container sprinkled with
> config magic to wire up their interfaces, and be done? Alternately, do
> they
> need to open up the war and rejigger it around?
Right now we're producing both a war and a jar. At google we're using the
jar and wiring up some customized RemoteContentFetchers and a
GadgetTokenDecoder. Other people might want the war.
The war is probably the best option for the black box solution. There are
definitely still some rough edges here, though, like providing a startup
script.
>
> -Brian
>
> On Fri, Apr 4, 2008 at 7:06 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>
> > I think the patch I send a few hours back was missing some things, here
> it
> > is again (and working). Sorry if that wasted your time..... please
> ignore if
> > you have already done it.
> >
> >
> > Ian
> >
> >
> >
> >
> >
> >
> >
> > On 4 Apr 2008, at 11:16, Cassie wrote:
> >
> > > Ian - your patch didn't come through.
> > >
> > > I am working on this as we speak and hope to have something checked in
> > > in just a couple hours (before my flight to london). If your patch
> > > works Ian - I'll gladly use it!
> > >
> > > - Cassie
> > >
> > >
> > >
> >
>
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Brian McCallister <br...@skife.org>.
What is the planned deployment story for java-shindig? Do we want people to
be able to take the war, drop it in a servlet container sprinkled with
config magic to wire up their interfaces, and be done? Alternately, do they
need to open up the war and rejigger it around?
-Brian
On Fri, Apr 4, 2008 at 7:06 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> I think the patch I send a few hours back was missing some things, here it
> is again (and working). Sorry if that wasted your time..... please ignore if
> you have already done it.
>
>
> Ian
>
>
>
>
>
>
>
> On 4 Apr 2008, at 11:16, Cassie wrote:
>
> > Ian - your patch didn't come through.
> >
> > I am working on this as we speak and hope to have something checked in
> > in just a couple hours (before my flight to london). If your patch
> > works Ian - I'll gladly use it!
> >
> > - Cassie
> >
> >
> >
>
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ie...@tfd.co.uk>.
I think the patch I send a few hours back was missing some things,
here it is again (and working). Sorry if that wasted your time.....
please ignore if you have already done it.
Ian
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ie...@tfd.co.uk>.
For completeness, Here is the patch, cut and paste, but I would be
happy to wait...
sorry for the long post.
<PATCH>
Index: java/gadgets/conf/opensocial.properties
===================================================================
Property changes on: java/gadgets/conf/opensocial.properties
___________________________________________________________________
Name: svn:eol-style
+ native
Index: java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
===================================================================
--- java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
(revision 644317)
+++ java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
(working copy)
@@ -17,26 +17,24 @@
*/
package org.apache.shindig.social.opensocial;
+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
import org.apache.shindig.social.GadgetDataHandler;
import org.apache.shindig.social.RequestItem;
import org.apache.shindig.social.ResponseError;
import org.apache.shindig.social.ResponseItem;
import org.apache.shindig.social.opensocial.model.Activity;
import org.apache.shindig.social.opensocial.model.IdSpec;
-import org.apache.shindig.social.samplecontainer.BasicActivitiesService;
-import org.apache.shindig.social.samplecontainer.BasicDataService;
-import org.apache.shindig.social.samplecontainer.BasicPeopleService;
-
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
-import java.util.ArrayList;
-import java.util.HashSet;
-import java.util.List;
-import java.util.Set;
-import java.util.logging.Level;
-import java.util.logging.Logger;
+import com.google.inject.Inject;
/**
* Servlet for serving the data required for opensocial.
@@ -47,10 +45,20 @@
= Logger.getLogger("org.apache.shindig.social");
// TODO: get through injection
+ /*
private static PeopleService peopleHandler = new BasicPeopleService();
private static DataService dataHandler = new BasicDataService();
private static ActivitiesService activitiesHandler
= new BasicActivitiesService();
+ */
+ @Inject
+ private PeopleService peopleHandler;
+
+ @Inject
+ private DataService dataHandler;
+
+ @Inject
+ private ActivitiesService activitiesHandler;
public enum OpenSocialDataType {
FETCH_PEOPLE,
Index: java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
===================================================================
--- java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
(revision 0)
+++ java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
(revision 0)
@@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations under the License.
+ */
+
+package org.apache.shindig.social.opensocial;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Arrays;
+import java.util.Properties;
+
+import org.apache.shindig.social.samplecontainer.BasicActivitiesService;
+import org.apache.shindig.social.samplecontainer.BasicDataService;
+import org.apache.shindig.social.samplecontainer.BasicPeopleService;
+import org.apache.shindig.util.ResourceLoader;
+
+import com.google.inject.AbstractModule;
+import com.google.inject.CreationException;
+import com.google.inject.Scopes;
+import com.google.inject.name.Names;
+import com.google.inject.spi.Message;
+
+/**
+ * @author ieb
+ */
+public class DeafultServiceModule extends AbstractModule
+{
+ private final Properties properties;
+
+ private final static String DEFAULT_PROPERTIES =
"opensocial.properties";
+
+ public DeafultServiceModule(Properties properties)
+ {
+ this.properties = properties;
+ }
+
+ /**
+ * Creates module with standard properties.
+ */
+ public DeafultServiceModule()
+ {
+ Properties properties = null;
+ try
+ {
+ InputStream is =
ResourceLoader.openResource(DEFAULT_PROPERTIES);
+ properties = new Properties();
+ properties.load(is);
+ }
+ catch (IOException e)
+ {
+
+ throw new CreationException(Arrays.asList(new Message(
+ "Unable to load properties: "
+ DEFAULT_PROPERTIES)));
+ }
+ this.properties = properties;
+ }
+
+ /** {@inheritDoc} */
+ @Override
+ public void configure()
+ {
+ Names.bindProperties(this.binder(), properties);
+
+ /* bind in the default services */
+
bind(ActivitiesService.class).to(BasicActivitiesService.class).in(
+ Scopes.SINGLETON);
+
bind(PeopleService.class).to(BasicPeopleService.class).in(Scopes.SINGLETON);
+
bind(DataService.class).to(BasicDataService.class).in(Scopes.SINGLETON);
+ }
+
+}
Property changes on:
java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
___________________________________________________________________
Name: svn:keywords
+ Date Revision Author HeadURL Id
Name: svn:eol-style
+ native
Index: java/gadgets/src/main/webapp/WEB-INF/web.xml
===================================================================
--- java/gadgets/src/main/webapp/WEB-INF/web.xml (revision 644317)
+++ java/gadgets/src/main/webapp/WEB-INF/web.xml (working copy)
@@ -26,7 +26,7 @@
<!-- If you have your own Guice module(s), put them here as a
colon-separated list. -->
<context-param>
<param-name>guice-modules</param-name>
- <param-value>org.apache.shindig.gadgets.http.HttpGuiceModule</param-value>
+ <param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.apache.shindig.social.opensocial.DeafultServiceModule</param-value>
</context-param>
<listener>
</PATCH>
On 04/04/2008, Cassie <do...@google.com> wrote:
> Ian - your patch didn't come through.
>
> I am working on this as we speak and hope to have something checked in
> in just a couple hours (before my flight to london). If your patch
> works Ian - I'll gladly use it!
>
>
> - Cassie
>
>
>
> On Fri, Apr 4, 2008 at 12:03 PM, Ian Boston <ia...@googlemail.com> wrote:
> > This is what I did to make my service injectable (I have my own
> > version of the DefaultServiceModule), patch attached. One cavet, its
> > the first time I have used Guice, so I expect its wrong, but if not
> > please feel free to use (in apache jira I would have ticked the ASF
> > license checkbox).
> >
> > Ian
> > (btw, I will not be in the slightest offended if you ignore the patch
> > :), I am only experimenting )
> >
> >
> >
> >
> >
> >
> > On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> > > On Fri, Apr 4, 2008 at 12:58 AM, Ian Boston <ia...@googlemail.com>
> > > wrote:
> > >
> > >
> > > > Would, longer term the intention be to define the services in a Guice
> > > > Module that was referenced in the web.xml ?
> > >
> > >
> > >
> > > This would be the case today, but someone needs to wire up guice injection
> > > in the social parts. The gadget renderer is thoroughly covered, but I only
> > > did the most basic stuff to make the social data stuff work correctly. Since
> > > that code is more subject to change than the renderer at the moment I
> > > thought it best to leave it up to people who are actually actively working
> > > with that code.
> > >
> > > --
> > >
> > > ~Kevin
> > >
> >
>
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ia...@googlemail.com>.
For completeness, Here is the patch, cut and paste, but I would be
happy to wait...
sorry for the long post.
<PATCH>
Index: java/gadgets/conf/opensocial.properties
===================================================================
Property changes on: java/gadgets/conf/opensocial.properties
___________________________________________________________________
Name: svn:eol-style
+ native
Index: java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
===================================================================
--- java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
(revision 644317)
+++ java/gadgets/src/main/java/org/apache/shindig/social/opensocial/OpenSocialDataHandler.java
(working copy)
@@ -17,26 +17,24 @@
*/
package org.apache.shindig.social.opensocial;
+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
import org.apache.shindig.social.GadgetDataHandler;
import org.apache.shindig.social.RequestItem;
import org.apache.shindig.social.ResponseError;
import org.apache.shindig.social.ResponseItem;
import org.apache.shindig.social.opensocial.model.Activity;
import org.apache.shindig.social.opensocial.model.IdSpec;
-import org.apache.shindig.social.samplecontainer.BasicActivitiesService;
-import org.apache.shindig.social.samplecontainer.BasicDataService;
-import org.apache.shindig.social.samplecontainer.BasicPeopleService;
-
import org.json.JSONArray;
import org.json.JSONException;
import org.json.JSONObject;
-import java.util.ArrayList;
-import java.util.HashSet;
-import java.util.List;
-import java.util.Set;
-import java.util.logging.Level;
-import java.util.logging.Logger;
+import com.google.inject.Inject;
/**
* Servlet for serving the data required for opensocial.
@@ -47,10 +45,20 @@
= Logger.getLogger("org.apache.shindig.social");
// TODO: get through injection
+ /*
private static PeopleService peopleHandler = new BasicPeopleService();
private static DataService dataHandler = new BasicDataService();
private static ActivitiesService activitiesHandler
= new BasicActivitiesService();
+ */
+ @Inject
+ private PeopleService peopleHandler;
+
+ @Inject
+ private DataService dataHandler;
+
+ @Inject
+ private ActivitiesService activitiesHandler;
public enum OpenSocialDataType {
FETCH_PEOPLE,
Index: java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
===================================================================
--- java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
(revision 0)
+++ java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
(revision 0)
@@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations under the License.
+ */
+
+package org.apache.shindig.social.opensocial;
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Arrays;
+import java.util.Properties;
+
+import org.apache.shindig.social.samplecontainer.BasicActivitiesService;
+import org.apache.shindig.social.samplecontainer.BasicDataService;
+import org.apache.shindig.social.samplecontainer.BasicPeopleService;
+import org.apache.shindig.util.ResourceLoader;
+
+import com.google.inject.AbstractModule;
+import com.google.inject.CreationException;
+import com.google.inject.Scopes;
+import com.google.inject.name.Names;
+import com.google.inject.spi.Message;
+
+/**
+ * @author ieb
+ */
+public class DeafultServiceModule extends AbstractModule
+{
+ private final Properties properties;
+
+ private final static String DEFAULT_PROPERTIES =
"opensocial.properties";
+
+ public DeafultServiceModule(Properties properties)
+ {
+ this.properties = properties;
+ }
+
+ /**
+ * Creates module with standard properties.
+ */
+ public DeafultServiceModule()
+ {
+ Properties properties = null;
+ try
+ {
+ InputStream is =
ResourceLoader.openResource(DEFAULT_PROPERTIES);
+ properties = new Properties();
+ properties.load(is);
+ }
+ catch (IOException e)
+ {
+
+ throw new CreationException(Arrays.asList(new Message(
+ "Unable to load properties: "
+ DEFAULT_PROPERTIES)));
+ }
+ this.properties = properties;
+ }
+
+ /** {@inheritDoc} */
+ @Override
+ public void configure()
+ {
+ Names.bindProperties(this.binder(), properties);
+
+ /* bind in the default services */
+
bind(ActivitiesService.class).to(BasicActivitiesService.class).in(
+ Scopes.SINGLETON);
+
bind(PeopleService.class).to(BasicPeopleService.class).in(Scopes.SINGLETON);
+
bind(DataService.class).to(BasicDataService.class).in(Scopes.SINGLETON);
+ }
+
+}
Property changes on:
java/gadgets/src/main/java/org/apache/shindig/social/opensocial/DeafultServiceModule.java
___________________________________________________________________
Name: svn:keywords
+ Date Revision Author HeadURL Id
Name: svn:eol-style
+ native
Index: java/gadgets/src/main/webapp/WEB-INF/web.xml
===================================================================
--- java/gadgets/src/main/webapp/WEB-INF/web.xml (revision 644317)
+++ java/gadgets/src/main/webapp/WEB-INF/web.xml (working copy)
@@ -26,7 +26,7 @@
<!-- If you have your own Guice module(s), put them here as a
colon-separated list. -->
<context-param>
<param-name>guice-modules</param-name>
- <param-value>org.apache.shindig.gadgets.http.HttpGuiceModule</param-value>
+ <param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.apache.shindig.social.opensocial.DeafultServiceModule</param-value>
</context-param>
<listener>
</PATCH>
On 04/04/2008, Cassie <do...@google.com> wrote:
> Ian - your patch didn't come through.
>
> I am working on this as we speak and hope to have something checked in
> in just a couple hours (before my flight to london). If your patch
> works Ian - I'll gladly use it!
>
>
> - Cassie
>
>
>
> On Fri, Apr 4, 2008 at 12:03 PM, Ian Boston <ia...@googlemail.com> wrote:
> > This is what I did to make my service injectable (I have my own
> > version of the DefaultServiceModule), patch attached. One cavet, its
> > the first time I have used Guice, so I expect its wrong, but if not
> > please feel free to use (in apache jira I would have ticked the ASF
> > license checkbox).
> >
> > Ian
> > (btw, I will not be in the slightest offended if you ignore the patch
> > :), I am only experimenting )
> >
> >
> >
> >
> >
> >
> > On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> > > On Fri, Apr 4, 2008 at 12:58 AM, Ian Boston <ia...@googlemail.com>
> > > wrote:
> > >
> > >
> > > > Would, longer term the intention be to define the services in a Guice
> > > > Module that was referenced in the web.xml ?
> > >
> > >
> > >
> > > This would be the case today, but someone needs to wire up guice injection
> > > in the social parts. The gadget renderer is thoroughly covered, but I only
> > > did the most basic stuff to make the social data stuff work correctly. Since
> > > that code is more subject to change than the renderer at the moment I
> > > thought it best to leave it up to people who are actually actively working
> > > with that code.
> > >
> > > --
> > >
> > > ~Kevin
> > >
> >
>
Re: Working on data integration guide for Shindig...
Posted by Cassie <do...@google.com>.
Ian - your patch didn't come through.
I am working on this as we speak and hope to have something checked in
in just a couple hours (before my flight to london). If your patch
works Ian - I'll gladly use it!
- Cassie
On Fri, Apr 4, 2008 at 12:03 PM, Ian Boston <ia...@googlemail.com> wrote:
> This is what I did to make my service injectable (I have my own
> version of the DefaultServiceModule), patch attached. One cavet, its
> the first time I have used Guice, so I expect its wrong, but if not
> please feel free to use (in apache jira I would have ticked the ASF
> license checkbox).
>
> Ian
> (btw, I will not be in the slightest offended if you ignore the patch
> :), I am only experimenting )
>
>
>
>
>
>
> On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> > On Fri, Apr 4, 2008 at 12:58 AM, Ian Boston <ia...@googlemail.com>
> > wrote:
> >
> >
> > > Would, longer term the intention be to define the services in a Guice
> > > Module that was referenced in the web.xml ?
> >
> >
> >
> > This would be the case today, but someone needs to wire up guice injection
> > in the social parts. The gadget renderer is thoroughly covered, but I only
> > did the most basic stuff to make the social data stuff work correctly. Since
> > that code is more subject to change than the renderer at the moment I
> > thought it best to leave it up to people who are actually actively working
> > with that code.
> >
> > --
> >
> > ~Kevin
> >
>
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ia...@googlemail.com>.
This is what I did to make my service injectable (I have my own
version of the DefaultServiceModule), patch attached. One cavet, its
the first time I have used Guice, so I expect its wrong, but if not
please feel free to use (in apache jira I would have ticked the ASF
license checkbox).
Ian
(btw, I will not be in the slightest offended if you ignore the patch
:), I am only experimenting )
On 04/04/2008, Kevin Brown <et...@google.com> wrote:
> On Fri, Apr 4, 2008 at 12:58 AM, Ian Boston <ia...@googlemail.com>
> wrote:
>
>
> > Would, longer term the intention be to define the services in a Guice
> > Module that was referenced in the web.xml ?
>
>
>
> This would be the case today, but someone needs to wire up guice injection
> in the social parts. The gadget renderer is thoroughly covered, but I only
> did the most basic stuff to make the social data stuff work correctly. Since
> that code is more subject to change than the renderer at the moment I
> thought it best to leave it up to people who are actually actively working
> with that code.
>
> --
>
> ~Kevin
>
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Fri, Apr 4, 2008 at 12:58 AM, Ian Boston <ia...@googlemail.com>
wrote:
> Would, longer term the intention be to define the services in a Guice
> Module that was referenced in the web.xml ?
This would be the case today, but someone needs to wire up guice injection
in the social parts. The gadget renderer is thoroughly covered, but I only
did the most basic stuff to make the social data stuff work correctly. Since
that code is more subject to change than the renderer at the moment I
thought it best to leave it up to people who are actually actively working
with that code.
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Ian Boston <ia...@googlemail.com>.
Would, longer term the intention be to define the services in a Guice
Module that was referenced in the web.xml ?
<context-param>
<param-name>guice-modules</param-name>
<param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.apache.shindig.gadgets.DefaultServiceModule</param-value>
</context-param>
or, for a custom service impl
<context-param>
<param-name>guice-modules</param-name>
<param-value>org.apache.shindig.gadgets.http.HttpGuiceModule:org.sakaiproject.shindig.SakaiServiceModule</param-value>
</context-param>
Or is that the wrong way to do it? ... just feeling my way in the dark.
Ian
On 03/04/2008, Ross Gardler <rg...@apache.org> wrote:
> Raymond Auge wrote:
>
> > The shindig plugin we developed works as a fire and forget app in all
> > the app server/servlet containers/RDBMS combinations that we support
> > (which is extensive, literally hundreds of combinations).
> >
> > What we're missing is that "injectable" datasource backend.
> >
> > Right now I'm flat out replacing the implementation of
> >
> org.apache.shindig.social.opensocial.OpenSocialDataHandler
> >
> > overriding the implementations of the Basic*Services.
> >
>
> It's a long way from perfect, but a really quick solution (for Java folk)
> is in the patch attached to SHINDIG-154. This allows the Basic*Sevices to be
> replaced by local classes defined in web.xml
>
> In our implmentation we have added our own services that talk to our
> existng back-end via the REST API, transform the data to the right XML
> format and then let shindig get on with it.
>
> It's quick and dirty, but it's simple and works.
>
> Ross
>
Re: Working on data integration guide for Shindig...
Posted by Ross Gardler <rg...@apache.org>.
Raymond Auge wrote:
> The shindig plugin we developed works as a fire and forget app in all
> the app server/servlet containers/RDBMS combinations that we support
> (which is extensive, literally hundreds of combinations).
>
> What we're missing is that "injectable" datasource backend.
>
> Right now I'm flat out replacing the implementation of
>
> org.apache.shindig.social.opensocial.OpenSocialDataHandler
>
> overriding the implementations of the Basic*Services.
It's a long way from perfect, but a really quick solution (for Java
folk) is in the patch attached to SHINDIG-154. This allows the
Basic*Sevices to be replaced by local classes defined in web.xml
In our implmentation we have added our own services that talk to our
existng back-end via the REST API, transform the data to the right XML
format and then let shindig get on with it.
It's quick and dirty, but it's simple and works.
Ross
Re: Working on data integration guide for Shindig...
Posted by Raymond Auge <ra...@liferay.com>.
The shindig plugin we developed works as a fire and forget app in all
the app server/servlet containers/RDBMS combinations that we support
(which is extensive, literally hundreds of combinations).
What we're missing is that "injectable" datasource backend.
Right now I'm flat out replacing the implementation of
org.apache.shindig.social.opensocial.OpenSocialDataHandler
overriding the implementations of the Basic*Services.
But that's not a very nice way of working with it. At the very least we
need some way to wire in an implementation. This way you could have X
backends bundled to handle the different possible scenarios, direct
JDBC, DAO Service Tier, RPC implementation, etc, while still allowing
for custom implementations.
In our case, we're plugging in directly to our generated DAO service
tier, so as to leverage existing caching infrastructure, cluster
support, etc..., which means we'd want to implement the backend as a
custom code anyway.
The question is "which is the most accepted way of building out these
plug-able backend implementations?"
You can go anywhere from
- classNames as servlet init-params in the web.xml file
- classpath properties files specifying implementation classes
... all the way to ...
- a Dependency Injection container like Spring...
What would be the solution of choice?
Ray
On Wed, 2008-04-02 at 21:34 -0400, Karim Jouini wrote:
> Hi,
>
> Very good idea, I'm actually waiting for a doc like that :-) (planning to
> start integrating OpenSocial in a couple of months from now).
>
> Thanks !
>
> Karim
>
> 2008/4/2, Vasu Nori <vn...@google.com>:
> >
> > On Wed, Apr 2, 2008 at 5:59 PM, Dan Peterson <dp...@google.com> wrote:
> >
> > > On Wed, Apr 2, 2008 at 5:53 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > On Wed, Apr 2, 2008 at 5:49 PM, Vasudeva Nori <va...@gmail.com>
> > > wrote:
> > > >
> > > > > On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cschalk@google.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Hello shindig-dev,
> > > > > >
> > > > > > It seems like a lot of the questions on shindig-dev are around how
> > > to
> > > > > wire
> > > > > > the OpenSocal API to a real backend. Given that, I'm in the
> > process
> > > of
> > > > > > putting together a guide on how to attach your local version of
> > > > Shindig
> > > > > to
> > > > > > a
> > > > > > native datasource.
> > > > >
> > > > >
> > > > > I don't understand meaning of "wiring to a native datasource" here.
> > > > > do you mean
> > > > >
> > > > > - how does one connect Shindig to some data source (like database)
> > > > > that is local to wherever Shindig is running in?
> > > > >
> > > > > If so, I don't think there is any magic to it at all.
> > > > > Shindig is a java application that could be hosted on any Java
> > > > application
> > > > > server such as JBoss, WebSphere etc using frameworks such Spring
> > > (i.e.,
> > > > > not
> > > > > just on servlet container such as Jetty, Tomcat).
> > > > > Java Application Servers have dealt with this problem of connecting
> > to
> > > > any
> > > > > datasource - be it a database or file system or another application
> > or
> > > > > just
> > > > > about anything else.
> > > > >
> > > > > Right now, I don't see anything in Shindig that precludes me from
> > > > hosting
> > > > > it
> > > > > on a Java App Server. Or, just add JDBC connectivity to talk to my
> > > > > database.
> > > > >
> > > > > As long as Shindig can play nicely with Java Application Servers,
> > > > Servlet
> > > > > Containers or any Java Framework, Shindig doesn't HAVE to worry
> > about
> > > > such
> > > > > details at all.
> > > >
> > >
> > > While Shindig doesn't have to worry about it, I imagine documentation
> > > would
> > > be useful for folks looking to implement and get running in production.
> > >
> >
> > that makes sense.
> > plus, I forgot all about php.
> >
> > in that case, would be nice to include documentation on how to get it
> > hosted
> > on JBoss/WebSphere/WebLogic etc and what to watch out for. I am planning
> > on
> > doing this. I will contribute as soon as I have the details. I imagine
> > others on this mailing list may already have done that.
> >
> >
> >
> > > Thanks for taking the lead on this, Chris!
> > >
> > > -Dan
> > >
> > >
> > > >
> > > > This is true for people using Shindig Java server in an existing Java
> > > > environment, but it's not true for people who want to deploy Shindig
> > in
> > > a
> > > > non-Java (and non-PHP) environment. Right now the only answers we have
> > > for
> > > > these people are:
> > > >
> > > > - Port Shindig to your language of choice
> > > >
> > > > or
> > > >
> > > > - Use Java or PHP
> > > >
> > > > The answer we want is:
> > > >
> > > > - Wire up some RPC calls (in a config file) to your back end and
> > respond
> > > > to
> > > > those calls appropriately.
> > > >
> > > >
> > > > >
> > > > > thanks
> > > > >
> > > > >
> > > > > >
> > > > > > Here's a draft set of items that I'm planning to cover in the
> > guide:
> > > > > >
> > > > > > Basics
> > > > > >
> > > > > >
> > > > > > 1. Quick review on how to install Shindig on your server.
> > > > > > - Testing some simple (non-OpenSocial) Gadgets on your
> > server.
> > > > > > 2. Testing an OpenSocial app within your Shindig environment
> > > > > > - Trying out the SampleContainer.
> > > > > > - Trying out some other simple OpenSocial apps with the
> > > > > > SampleContainer
> > > > > > - Playing around with simple XML based state data within the
> > > > > > SampleContainer
> > > > > >
> > > > > >
> > > > > > Intermediate-Advanced
> > > > > >
> > > > > >
> > > > > > 1. State Data access concepts
> > > > > > - Reviewing concepts on how to access data
> > > > > > - The all Java approach - implementing interfaces
> > > > > > - The RPC approach - creating http based response
> > > > > > mechanisms
> > > > > > 2. Building your own data access using either
> > > > > > - Java approach
> > > > > > - Getting familiar with the classes and interfaces in
> > > > > > org.apache.shindig.social.*.
> > > > > > - Implement the provided interfaces to access custom data.
> > > > > > - Language neutral RPC approach
> > > > > > - How to build your own http mechanism in PHP to serve
> > > > > > social data
> > > > > >
> > > > > >
> > > > > > Let me know if you any suggestions or additions, and we'll
> > continue
> > > to
> > > > > > flesh
> > > > > > this out and publish it.
> > > > > >
> > > > > > Thanks,
> > > > > > -Chris
> > > > > >
> > > > > > --
> > > > > > Chris Schalk, Google Developer Advocate
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > > >
> > >
> >
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Re: Working on data integration guide for Shindig...
Posted by Karim Jouini <ka...@jouini.info>.
Hi,
Very good idea, I'm actually waiting for a doc like that :-) (planning to
start integrating OpenSocial in a couple of months from now).
Thanks !
Karim
2008/4/2, Vasu Nori <vn...@google.com>:
>
> On Wed, Apr 2, 2008 at 5:59 PM, Dan Peterson <dp...@google.com> wrote:
>
> > On Wed, Apr 2, 2008 at 5:53 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > On Wed, Apr 2, 2008 at 5:49 PM, Vasudeva Nori <va...@gmail.com>
> > wrote:
> > >
> > > > On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cschalk@google.com
> >
> > > > wrote:
> > > >
> > > > > Hello shindig-dev,
> > > > >
> > > > > It seems like a lot of the questions on shindig-dev are around how
> > to
> > > > wire
> > > > > the OpenSocal API to a real backend. Given that, I'm in the
> process
> > of
> > > > > putting together a guide on how to attach your local version of
> > > Shindig
> > > > to
> > > > > a
> > > > > native datasource.
> > > >
> > > >
> > > > I don't understand meaning of "wiring to a native datasource" here.
> > > > do you mean
> > > >
> > > > - how does one connect Shindig to some data source (like database)
> > > > that is local to wherever Shindig is running in?
> > > >
> > > > If so, I don't think there is any magic to it at all.
> > > > Shindig is a java application that could be hosted on any Java
> > > application
> > > > server such as JBoss, WebSphere etc using frameworks such Spring
> > (i.e.,
> > > > not
> > > > just on servlet container such as Jetty, Tomcat).
> > > > Java Application Servers have dealt with this problem of connecting
> to
> > > any
> > > > datasource - be it a database or file system or another application
> or
> > > > just
> > > > about anything else.
> > > >
> > > > Right now, I don't see anything in Shindig that precludes me from
> > > hosting
> > > > it
> > > > on a Java App Server. Or, just add JDBC connectivity to talk to my
> > > > database.
> > > >
> > > > As long as Shindig can play nicely with Java Application Servers,
> > > Servlet
> > > > Containers or any Java Framework, Shindig doesn't HAVE to worry
> about
> > > such
> > > > details at all.
> > >
> >
> > While Shindig doesn't have to worry about it, I imagine documentation
> > would
> > be useful for folks looking to implement and get running in production.
> >
>
> that makes sense.
> plus, I forgot all about php.
>
> in that case, would be nice to include documentation on how to get it
> hosted
> on JBoss/WebSphere/WebLogic etc and what to watch out for. I am planning
> on
> doing this. I will contribute as soon as I have the details. I imagine
> others on this mailing list may already have done that.
>
>
>
> > Thanks for taking the lead on this, Chris!
> >
> > -Dan
> >
> >
> > >
> > > This is true for people using Shindig Java server in an existing Java
> > > environment, but it's not true for people who want to deploy Shindig
> in
> > a
> > > non-Java (and non-PHP) environment. Right now the only answers we have
> > for
> > > these people are:
> > >
> > > - Port Shindig to your language of choice
> > >
> > > or
> > >
> > > - Use Java or PHP
> > >
> > > The answer we want is:
> > >
> > > - Wire up some RPC calls (in a config file) to your back end and
> respond
> > > to
> > > those calls appropriately.
> > >
> > >
> > > >
> > > > thanks
> > > >
> > > >
> > > > >
> > > > > Here's a draft set of items that I'm planning to cover in the
> guide:
> > > > >
> > > > > Basics
> > > > >
> > > > >
> > > > > 1. Quick review on how to install Shindig on your server.
> > > > > - Testing some simple (non-OpenSocial) Gadgets on your
> server.
> > > > > 2. Testing an OpenSocial app within your Shindig environment
> > > > > - Trying out the SampleContainer.
> > > > > - Trying out some other simple OpenSocial apps with the
> > > > > SampleContainer
> > > > > - Playing around with simple XML based state data within the
> > > > > SampleContainer
> > > > >
> > > > >
> > > > > Intermediate-Advanced
> > > > >
> > > > >
> > > > > 1. State Data access concepts
> > > > > - Reviewing concepts on how to access data
> > > > > - The all Java approach - implementing interfaces
> > > > > - The RPC approach - creating http based response
> > > > > mechanisms
> > > > > 2. Building your own data access using either
> > > > > - Java approach
> > > > > - Getting familiar with the classes and interfaces in
> > > > > org.apache.shindig.social.*.
> > > > > - Implement the provided interfaces to access custom data.
> > > > > - Language neutral RPC approach
> > > > > - How to build your own http mechanism in PHP to serve
> > > > > social data
> > > > >
> > > > >
> > > > > Let me know if you any suggestions or additions, and we'll
> continue
> > to
> > > > > flesh
> > > > > this out and publish it.
> > > > >
> > > > > Thanks,
> > > > > -Chris
> > > > >
> > > > > --
> > > > > Chris Schalk, Google Developer Advocate
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> >
>
Re: Working on data integration guide for Shindig...
Posted by Vasu Nori <vn...@google.com>.
On Wed, Apr 2, 2008 at 5:59 PM, Dan Peterson <dp...@google.com> wrote:
> On Wed, Apr 2, 2008 at 5:53 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Wed, Apr 2, 2008 at 5:49 PM, Vasudeva Nori <va...@gmail.com>
> wrote:
> >
> > > On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cs...@google.com>
> > > wrote:
> > >
> > > > Hello shindig-dev,
> > > >
> > > > It seems like a lot of the questions on shindig-dev are around how
> to
> > > wire
> > > > the OpenSocal API to a real backend. Given that, I'm in the process
> of
> > > > putting together a guide on how to attach your local version of
> > Shindig
> > > to
> > > > a
> > > > native datasource.
> > >
> > >
> > > I don't understand meaning of "wiring to a native datasource" here.
> > > do you mean
> > >
> > > - how does one connect Shindig to some data source (like database)
> > > that is local to wherever Shindig is running in?
> > >
> > > If so, I don't think there is any magic to it at all.
> > > Shindig is a java application that could be hosted on any Java
> > application
> > > server such as JBoss, WebSphere etc using frameworks such Spring
> (i.e.,
> > > not
> > > just on servlet container such as Jetty, Tomcat).
> > > Java Application Servers have dealt with this problem of connecting to
> > any
> > > datasource - be it a database or file system or another application or
> > > just
> > > about anything else.
> > >
> > > Right now, I don't see anything in Shindig that precludes me from
> > hosting
> > > it
> > > on a Java App Server. Or, just add JDBC connectivity to talk to my
> > > database.
> > >
> > > As long as Shindig can play nicely with Java Application Servers,
> > Servlet
> > > Containers or any Java Framework, Shindig doesn't HAVE to worry about
> > such
> > > details at all.
> >
>
> While Shindig doesn't have to worry about it, I imagine documentation
> would
> be useful for folks looking to implement and get running in production.
>
that makes sense.
plus, I forgot all about php.
in that case, would be nice to include documentation on how to get it hosted
on JBoss/WebSphere/WebLogic etc and what to watch out for. I am planning on
doing this. I will contribute as soon as I have the details. I imagine
others on this mailing list may already have done that.
> Thanks for taking the lead on this, Chris!
>
> -Dan
>
>
> >
> > This is true for people using Shindig Java server in an existing Java
> > environment, but it's not true for people who want to deploy Shindig in
> a
> > non-Java (and non-PHP) environment. Right now the only answers we have
> for
> > these people are:
> >
> > - Port Shindig to your language of choice
> >
> > or
> >
> > - Use Java or PHP
> >
> > The answer we want is:
> >
> > - Wire up some RPC calls (in a config file) to your back end and respond
> > to
> > those calls appropriately.
> >
> >
> > >
> > > thanks
> > >
> > >
> > > >
> > > > Here's a draft set of items that I'm planning to cover in the guide:
> > > >
> > > > Basics
> > > >
> > > >
> > > > 1. Quick review on how to install Shindig on your server.
> > > > - Testing some simple (non-OpenSocial) Gadgets on your server.
> > > > 2. Testing an OpenSocial app within your Shindig environment
> > > > - Trying out the SampleContainer.
> > > > - Trying out some other simple OpenSocial apps with the
> > > > SampleContainer
> > > > - Playing around with simple XML based state data within the
> > > > SampleContainer
> > > >
> > > >
> > > > Intermediate-Advanced
> > > >
> > > >
> > > > 1. State Data access concepts
> > > > - Reviewing concepts on how to access data
> > > > - The all Java approach - implementing interfaces
> > > > - The RPC approach - creating http based response
> > > > mechanisms
> > > > 2. Building your own data access using either
> > > > - Java approach
> > > > - Getting familiar with the classes and interfaces in
> > > > org.apache.shindig.social.*.
> > > > - Implement the provided interfaces to access custom data.
> > > > - Language neutral RPC approach
> > > > - How to build your own http mechanism in PHP to serve
> > > > social data
> > > >
> > > >
> > > > Let me know if you any suggestions or additions, and we'll continue
> to
> > > > flesh
> > > > this out and publish it.
> > > >
> > > > Thanks,
> > > > -Chris
> > > >
> > > > --
> > > > Chris Schalk, Google Developer Advocate
> > > >
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
Re: Working on data integration guide for Shindig...
Posted by Dan Peterson <dp...@google.com>.
On Wed, Apr 2, 2008 at 5:53 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Apr 2, 2008 at 5:49 PM, Vasudeva Nori <va...@gmail.com> wrote:
>
> > On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cs...@google.com>
> > wrote:
> >
> > > Hello shindig-dev,
> > >
> > > It seems like a lot of the questions on shindig-dev are around how to
> > wire
> > > the OpenSocal API to a real backend. Given that, I'm in the process of
> > > putting together a guide on how to attach your local version of
> Shindig
> > to
> > > a
> > > native datasource.
> >
> >
> > I don't understand meaning of "wiring to a native datasource" here.
> > do you mean
> >
> > - how does one connect Shindig to some data source (like database)
> > that is local to wherever Shindig is running in?
> >
> > If so, I don't think there is any magic to it at all.
> > Shindig is a java application that could be hosted on any Java
> application
> > server such as JBoss, WebSphere etc using frameworks such Spring (i.e.,
> > not
> > just on servlet container such as Jetty, Tomcat).
> > Java Application Servers have dealt with this problem of connecting to
> any
> > datasource - be it a database or file system or another application or
> > just
> > about anything else.
> >
> > Right now, I don't see anything in Shindig that precludes me from
> hosting
> > it
> > on a Java App Server. Or, just add JDBC connectivity to talk to my
> > database.
> >
> > As long as Shindig can play nicely with Java Application Servers,
> Servlet
> > Containers or any Java Framework, Shindig doesn't HAVE to worry about
> such
> > details at all.
>
While Shindig doesn't have to worry about it, I imagine documentation would
be useful for folks looking to implement and get running in production.
Thanks for taking the lead on this, Chris!
-Dan
>
> This is true for people using Shindig Java server in an existing Java
> environment, but it's not true for people who want to deploy Shindig in a
> non-Java (and non-PHP) environment. Right now the only answers we have for
> these people are:
>
> - Port Shindig to your language of choice
>
> or
>
> - Use Java or PHP
>
> The answer we want is:
>
> - Wire up some RPC calls (in a config file) to your back end and respond
> to
> those calls appropriately.
>
>
> >
> > thanks
> >
> >
> > >
> > > Here's a draft set of items that I'm planning to cover in the guide:
> > >
> > > Basics
> > >
> > >
> > > 1. Quick review on how to install Shindig on your server.
> > > - Testing some simple (non-OpenSocial) Gadgets on your server.
> > > 2. Testing an OpenSocial app within your Shindig environment
> > > - Trying out the SampleContainer.
> > > - Trying out some other simple OpenSocial apps with the
> > > SampleContainer
> > > - Playing around with simple XML based state data within the
> > > SampleContainer
> > >
> > >
> > > Intermediate-Advanced
> > >
> > >
> > > 1. State Data access concepts
> > > - Reviewing concepts on how to access data
> > > - The all Java approach - implementing interfaces
> > > - The RPC approach - creating http based response
> > > mechanisms
> > > 2. Building your own data access using either
> > > - Java approach
> > > - Getting familiar with the classes and interfaces in
> > > org.apache.shindig.social.*.
> > > - Implement the provided interfaces to access custom data.
> > > - Language neutral RPC approach
> > > - How to build your own http mechanism in PHP to serve
> > > social data
> > >
> > >
> > > Let me know if you any suggestions or additions, and we'll continue to
> > > flesh
> > > this out and publish it.
> > >
> > > Thanks,
> > > -Chris
> > >
> > > --
> > > Chris Schalk, Google Developer Advocate
> > >
> >
>
>
>
> --
> ~Kevin
>
Re: Working on data integration guide for Shindig...
Posted by Kevin Brown <et...@google.com>.
On Wed, Apr 2, 2008 at 5:49 PM, Vasudeva Nori <va...@gmail.com> wrote:
> On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cs...@google.com>
> wrote:
>
> > Hello shindig-dev,
> >
> > It seems like a lot of the questions on shindig-dev are around how to
> wire
> > the OpenSocal API to a real backend. Given that, I'm in the process of
> > putting together a guide on how to attach your local version of Shindig
> to
> > a
> > native datasource.
>
>
> I don't understand meaning of "wiring to a native datasource" here.
> do you mean
>
> - how does one connect Shindig to some data source (like database)
> that is local to wherever Shindig is running in?
>
> If so, I don't think there is any magic to it at all.
> Shindig is a java application that could be hosted on any Java application
> server such as JBoss, WebSphere etc using frameworks such Spring (i.e.,
> not
> just on servlet container such as Jetty, Tomcat).
> Java Application Servers have dealt with this problem of connecting to any
> datasource - be it a database or file system or another application or
> just
> about anything else.
>
> Right now, I don't see anything in Shindig that precludes me from hosting
> it
> on a Java App Server. Or, just add JDBC connectivity to talk to my
> database.
>
> As long as Shindig can play nicely with Java Application Servers, Servlet
> Containers or any Java Framework, Shindig doesn't HAVE to worry about such
> details at all.
This is true for people using Shindig Java server in an existing Java
environment, but it's not true for people who want to deploy Shindig in a
non-Java (and non-PHP) environment. Right now the only answers we have for
these people are:
- Port Shindig to your language of choice
or
- Use Java or PHP
The answer we want is:
- Wire up some RPC calls (in a config file) to your back end and respond to
those calls appropriately.
>
> thanks
>
>
> >
> > Here's a draft set of items that I'm planning to cover in the guide:
> >
> > Basics
> >
> >
> > 1. Quick review on how to install Shindig on your server.
> > - Testing some simple (non-OpenSocial) Gadgets on your server.
> > 2. Testing an OpenSocial app within your Shindig environment
> > - Trying out the SampleContainer.
> > - Trying out some other simple OpenSocial apps with the
> > SampleContainer
> > - Playing around with simple XML based state data within the
> > SampleContainer
> >
> >
> > Intermediate-Advanced
> >
> >
> > 1. State Data access concepts
> > - Reviewing concepts on how to access data
> > - The all Java approach - implementing interfaces
> > - The RPC approach - creating http based response
> > mechanisms
> > 2. Building your own data access using either
> > - Java approach
> > - Getting familiar with the classes and interfaces in
> > org.apache.shindig.social.*.
> > - Implement the provided interfaces to access custom data.
> > - Language neutral RPC approach
> > - How to build your own http mechanism in PHP to serve
> > social data
> >
> >
> > Let me know if you any suggestions or additions, and we'll continue to
> > flesh
> > this out and publish it.
> >
> > Thanks,
> > -Chris
> >
> > --
> > Chris Schalk, Google Developer Advocate
> >
>
--
~Kevin
Re: Working on data integration guide for Shindig...
Posted by Vasudeva Nori <va...@gmail.com>.
On Wed, Apr 2, 2008 at 4:50 PM, Christian Schalk <cs...@google.com> wrote:
> Hello shindig-dev,
>
> It seems like a lot of the questions on shindig-dev are around how to wire
> the OpenSocal API to a real backend. Given that, I'm in the process of
> putting together a guide on how to attach your local version of Shindig to
> a
> native datasource.
I don't understand meaning of "wiring to a native datasource" here.
do you mean
- how does one connect Shindig to some data source (like database)
that is local to wherever Shindig is running in?
If so, I don't think there is any magic to it at all.
Shindig is a java application that could be hosted on any Java application
server such as JBoss, WebSphere etc using frameworks such Spring (i.e., not
just on servlet container such as Jetty, Tomcat).
Java Application Servers have dealt with this problem of connecting to any
datasource - be it a database or file system or another application or just
about anything else.
Right now, I don't see anything in Shindig that precludes me from hosting it
on a Java App Server. Or, just add JDBC connectivity to talk to my database.
As long as Shindig can play nicely with Java Application Servers, Servlet
Containers or any Java Framework, Shindig doesn't HAVE to worry about such
details at all.
thanks
>
> Here's a draft set of items that I'm planning to cover in the guide:
>
> Basics
>
>
> 1. Quick review on how to install Shindig on your server.
> - Testing some simple (non-OpenSocial) Gadgets on your server.
> 2. Testing an OpenSocial app within your Shindig environment
> - Trying out the SampleContainer.
> - Trying out some other simple OpenSocial apps with the
> SampleContainer
> - Playing around with simple XML based state data within the
> SampleContainer
>
>
> Intermediate-Advanced
>
>
> 1. State Data access concepts
> - Reviewing concepts on how to access data
> - The all Java approach - implementing interfaces
> - The RPC approach - creating http based response
> mechanisms
> 2. Building your own data access using either
> - Java approach
> - Getting familiar with the classes and interfaces in
> org.apache.shindig.social.*.
> - Implement the provided interfaces to access custom data.
> - Language neutral RPC approach
> - How to build your own http mechanism in PHP to serve
> social data
>
>
> Let me know if you any suggestions or additions, and we'll continue to
> flesh
> this out and publish it.
>
> Thanks,
> -Chris
>
> --
> Chris Schalk, Google Developer Advocate
>