You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@google.com> on 2008/04/14 12:07:54 UTC
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./
java/social-api/ java/social-api/src/ java/social-api/src/main/
java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
to follow up on this change I am trying to move the social/* classes
out of the java/gadgets package and into java/social-api
the social classes have the following gadgets dependencies:
// security token stuff
import org.apache.shindig.gadgets.GadgetException;
import org.apache.shindig.gadgets.GadgetToken;
import org.apache.shindig.gadgets.GadgetTokenDecoder;
// guice stuff
import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...)
// fetching remote file stuff
import org.apache.shindig.gadgets.BasicRemoteContentFetcher;
import org.apache.shindig.gadgets.GadgetException;
import org.apache.shindig.gadgets.RemoteContent;
import org.apache.shindig.gadgets.RemoteContentFetcher;
import org.apache.shindig.gadgets.RemoteContentRequest;
Anybody have any ideas/opinions as to how we handle these things?
Also - would people prefer that the social-api host the
samplecontainer, or the gadgets server? Same goes for the rest of the
javascript samplex.html and other files. The gadgets server will still
serve the opensocial gadget js. No matter which one we pick we are
going to need to do some sort of forwarding servlet or proxy thing or
a config of some sort which puts the gadget iframe url on the same
domain as the socialdata servlets so that the js can xhr. Any opinions
on this piece?
Thanks.
- Cassie
On Fri, Apr 11, 2008 at 4:04 AM, <db...@apache.org> wrote:
> Author: dbentley
> Date: Thu Apr 10 19:04:44 2008
> New Revision: 647030
>
> URL: http://svn.apache.org/viewvc?rev=647030&view=rev
> Log:
> Initial check-in of the social-api build.
>
>
> Added:
> incubator/shindig/trunk/java/social-api/
> incubator/shindig/trunk/java/social-api/pom.xml
> incubator/shindig/trunk/java/social-api/src/
> incubator/shindig/trunk/java/social-api/src/main/
> incubator/shindig/trunk/java/social-api/src/main/webapp/
> incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/
> incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml
> Modified:
> incubator/shindig/trunk/pom.xml
>
> Added: incubator/shindig/trunk/java/social-api/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api/pom.xml?rev=647030&view=auto
> ==============================================================================
> --- incubator/shindig/trunk/java/social-api/pom.xml (added)
> +++ incubator/shindig/trunk/java/social-api/pom.xml Thu Apr 10 19:04:44 2008
> @@ -0,0 +1,143 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<!--
> +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.
> +-->
> +<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> + <parent>
> + <groupId>org.apache.shindig</groupId>
> + <artifactId>shindig-parent</artifactId>
> + <version>1-SNAPSHOT</version>
> + <relativePath>../../pom/parent/pom.xml</relativePath>
> + </parent>
> + <modelVersion>4.0.0</modelVersion>
> + <groupId>org.apache.shindig</groupId>
> + <artifactId>social-api</artifactId>
> + <version>1-SNAPSHOT</version>
> + <packaging>war</packaging>
> + <name>Apache Shindig Java REST API Server</name>
> + <description>
> + Server part of Shindig for hosting OpenSocial Data APIs.
> + </description>
> +
> + <scm>
> + <connection>scm:svn:http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api</connection>
> + <developerConnection>scm:svn:https://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api</developerConnection>
> + <url>http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api</url>
> + </scm>
> +
> + <build>
> + <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
> + <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
> + <outputDirectory>${basedir}/target/classes</outputDirectory>
> + <testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
> + <finalName>social-api</finalName>
> + <plugins>
> + <plugin>
> + <groupId>org.apache.maven.plugins</groupId>
> + <artifactId>maven-war-plugin</artifactId>
> + </plugin>
> + <plugin>
> + <groupId>org.apache.maven.plugins </groupId>
> + <artifactId>maven-eclipse-plugin</artifactId>
> + </plugin>
> + <plugin>
> + <artifactId>maven-compiler-plugin</artifactId>
> + <configuration>
> + <source>1.5</source>
> + <target>1.5</target>
> + <fork>true</fork>
> + </configuration>
> + </plugin>
> + <plugin>
> + <artifactId>maven-source-plugin</artifactId>
> + <executions>
> + <execution>
> + <id>attach-sources</id>
> + <phase>package</phase>
> + <goals>
> + <goal>jar</goal>
> + </goals>
> + </execution>
> + </executions>
> + <configuration>
> + <excludeResources>true</excludeResources>
> + <attach>true</attach>
> + </configuration>
> + </plugin>
> + <plugin>
> + <groupId>org.mortbay.jetty</groupId>
> + <artifactId>maven-jetty-plugin</artifactId>
> + </plugin>
> + <plugin>
> + <groupId>org.apache.maven.plugins</groupId>
> + <artifactId>maven-jar-plugin</artifactId>
> + <executions>
> + <execution>
> + <phase>package</phase>
> + <goals>
> + <goal>jar</goal>
> + </goals>
> + </execution>
> + </executions>
> + </plugin>
> + </plugins>
> + </build>
> +
> + <repositories>
> + <!-- For Abdera -->
> + <repository>
> + <id>apache-incubating</id>
> + <name>Apache Incubating Snapshot Repository</name>
> + <url>http://people.apache.org/repo/m2-snapshot-repository</url>
> + <snapshots>
> + <enabled>true</enabled>
> + </snapshots>
> + </repository>
> + </repositories>
> +
> + <dependencies>
> + <dependency>
> + <groupId>org.json</groupId>
> + <artifactId>json</artifactId>
> + <version>20070829</version>
> + </dependency>
> + <dependency>
> + <groupId>junit</groupId>
> + <artifactId>junit</artifactId>
> + <version>4.4</version>
> + <scope>test</scope>
> + </dependency>
> + <dependency>
> + <groupId>org.easymock</groupId>
> + <artifactId>easymock</artifactId>
> + <version>2.3</version>
> + <scope>test</scope>
> + </dependency>
> + <dependency>
> + <groupId>org.easymock</groupId>
> + <artifactId>easymockclassextension</artifactId>
> + <version>2.2.2</version>
> + <scope>test</scope>
> + </dependency>
> + <dependency>
> + <version>0.4.0-incubating-SNAPSHOT</version>
> + <groupId>org.apache.abdera</groupId>
> + <artifactId>abdera-server</artifactId>
> + </dependency>
> + </dependencies>
> +</project>
>
> Added: incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml
> URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml?rev=647030&view=auto
> ==============================================================================
> --- incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml (added)
> +++ incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml Thu Apr 10 19:04:44 2008
> @@ -0,0 +1,25 @@
> +<?xml version="1.0"?>
> +<!--
> + 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.
> +-->
> +<!DOCTYPE web-app
> + PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> + "http://java.sun.com/dtd/web-app_2_3.dtd">
> +
> +<web-app>
> +</web-app>
>
> Modified: incubator/shindig/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/pom.xml?rev=647030&r1=647029&r2=647030&view=diff
> ==============================================================================
> --- incubator/shindig/trunk/pom.xml (original)
> +++ incubator/shindig/trunk/pom.xml Thu Apr 10 19:04:44 2008
> @@ -62,6 +62,15 @@
> <module>java/gadgets</module>
> </modules>
> </profile>
> +
> + <!-- profile to build java/rest-api -->
> + <profile>
> + <id>java/social-api</id>
> + <modules>
> + <module>java/social-api</module>
> + </modules>
> + </profile>
> +
> </profiles>
>
> <scm>
>
>
>
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./ java/social-api/ java/social-api/src/ java/social-api/src/main/ java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by David Primmer <da...@gmail.com>.
Thanks for starting into this Cassie. Those of us working on the API
server are very interested in this refactoring. We currently have a
lot of work-arounds for the fact that the code is not split up and we
can't keep up with head because constant integration would be too
messy.
I think Kevin mentioned having the guice stuff be separated so what
that means to me is that there's roughly a pom to guice module mapping
where if the stuff is build as an artifact, if it uses guice, it needs
a guice module.
In other projects I've seen the sample code, which usually use many
parts of the over-all project, in it's own root location. Because it's
all-inclusive (the samplecontainer, the sample api gateway, a sample
static file server, whatever) and because it's easier to locate for
people who first open the package, I'd say put it at the root of
shindig.
I don't know what was most-liked named for the common location,
/java/comon? But I'd start moving stuff there, then, since we'll have
at least 3 java pom.xml's, I'd do a root pom.xml for all Java code
(this factor out some of the dupe code and ensure consistent java
build rules.)
davep
On Mon, Apr 14, 2008 at 3:07 AM, Cassie <do...@google.com> wrote:
> to follow up on this change I am trying to move the social/* classes
> out of the java/gadgets package and into java/social-api
>
> the social classes have the following gadgets dependencies:
>
> // security token stuff
> import org.apache.shindig.gadgets.GadgetException;
> import org.apache.shindig.gadgets.GadgetToken;
> import org.apache.shindig.gadgets.GadgetTokenDecoder;
>
> // guice stuff
> import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...)
>
> // fetching remote file stuff
> import org.apache.shindig.gadgets.BasicRemoteContentFetcher;
> import org.apache.shindig.gadgets.GadgetException;
> import org.apache.shindig.gadgets.RemoteContent;
> import org.apache.shindig.gadgets.RemoteContentFetcher;
> import org.apache.shindig.gadgets.RemoteContentRequest;
>
>
> Anybody have any ideas/opinions as to how we handle these things?
>
> Also - would people prefer that the social-api host the
> samplecontainer, or the gadgets server? Same goes for the rest of the
> javascript samplex.html and other files. The gadgets server will still
> serve the opensocial gadget js. No matter which one we pick we are
> going to need to do some sort of forwarding servlet or proxy thing or
> a config of some sort which puts the gadget iframe url on the same
> domain as the socialdata servlets so that the js can xhr. Any opinions
> on this piece?
>
> Thanks.
>
> - Cassie
>
>
>
>
> On Fri, Apr 11, 2008 at 4:04 AM, <db...@apache.org> wrote:
> > Author: dbentley
> > Date: Thu Apr 10 19:04:44 2008
> > New Revision: 647030
> >
> > URL: http://svn.apache.org/viewvc?rev=647030&view=rev
> > Log:
> > Initial check-in of the social-api build.
> >
> >
> > Added:
> > incubator/shindig/trunk/java/social-api/
> > incubator/shindig/trunk/java/social-api/pom.xml
> > incubator/shindig/trunk/java/social-api/src/
> > incubator/shindig/trunk/java/social-api/src/main/
> > incubator/shindig/trunk/java/social-api/src/main/webapp/
> > incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/
> > incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml
> > Modified:
> > incubator/shindig/trunk/pom.xml
> >
> > Added: incubator/shindig/trunk/java/social-api/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api/pom.xml?rev=647030&view=auto
> > ==============================================================================
> > --- incubator/shindig/trunk/java/social-api/pom.xml (added)
> > +++ incubator/shindig/trunk/java/social-api/pom.xml Thu Apr 10 19:04:44 2008
> > @@ -0,0 +1,143 @@
> > +<?xml version="1.0" encoding="UTF-8"?>
> > +<!--
> > +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.
> > +-->
> > +<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> > + <parent>
> > + <groupId>org.apache.shindig</groupId>
> > + <artifactId>shindig-parent</artifactId>
> > + <version>1-SNAPSHOT</version>
> > + <relativePath>../../pom/parent/pom.xml</relativePath>
> > + </parent>
> > + <modelVersion>4.0.0</modelVersion>
> > + <groupId>org.apache.shindig</groupId>
> > + <artifactId>social-api</artifactId>
> > + <version>1-SNAPSHOT</version>
> > + <packaging>war</packaging>
> > + <name>Apache Shindig Java REST API Server</name>
> > + <description>
> > + Server part of Shindig for hosting OpenSocial Data APIs.
> > + </description>
> > +
> > + <scm>
> > + <connection>scm:svn:http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api</connection>
> > + <developerConnection>scm:svn:https://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api</developerConnection>
> > + <url>http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api</url>
> > + </scm>
> > +
> > + <build>
> > + <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
> > + <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
> > + <outputDirectory>${basedir}/target/classes</outputDirectory>
> > + <testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
> > + <finalName>social-api</finalName>
> > + <plugins>
> > + <plugin>
> > + <groupId>org.apache.maven.plugins</groupId>
> > + <artifactId>maven-war-plugin</artifactId>
> > + </plugin>
> > + <plugin>
> > + <groupId>org.apache.maven.plugins </groupId>
> > + <artifactId>maven-eclipse-plugin</artifactId>
> > + </plugin>
> > + <plugin>
> > + <artifactId>maven-compiler-plugin</artifactId>
> > + <configuration>
> > + <source>1.5</source>
> > + <target>1.5</target>
> > + <fork>true</fork>
> > + </configuration>
> > + </plugin>
> > + <plugin>
> > + <artifactId>maven-source-plugin</artifactId>
> > + <executions>
> > + <execution>
> > + <id>attach-sources</id>
> > + <phase>package</phase>
> > + <goals>
> > + <goal>jar</goal>
> > + </goals>
> > + </execution>
> > + </executions>
> > + <configuration>
> > + <excludeResources>true</excludeResources>
> > + <attach>true</attach>
> > + </configuration>
> > + </plugin>
> > + <plugin>
> > + <groupId>org.mortbay.jetty</groupId>
> > + <artifactId>maven-jetty-plugin</artifactId>
> > + </plugin>
> > + <plugin>
> > + <groupId>org.apache.maven.plugins</groupId>
> > + <artifactId>maven-jar-plugin</artifactId>
> > + <executions>
> > + <execution>
> > + <phase>package</phase>
> > + <goals>
> > + <goal>jar</goal>
> > + </goals>
> > + </execution>
> > + </executions>
> > + </plugin>
> > + </plugins>
> > + </build>
> > +
> > + <repositories>
> > + <!-- For Abdera -->
> > + <repository>
> > + <id>apache-incubating</id>
> > + <name>Apache Incubating Snapshot Repository</name>
> > + <url>http://people.apache.org/repo/m2-snapshot-repository</url>
> > + <snapshots>
> > + <enabled>true</enabled>
> > + </snapshots>
> > + </repository>
> > + </repositories>
> > +
> > + <dependencies>
> > + <dependency>
> > + <groupId>org.json</groupId>
> > + <artifactId>json</artifactId>
> > + <version>20070829</version>
> > + </dependency>
> > + <dependency>
> > + <groupId>junit</groupId>
> > + <artifactId>junit</artifactId>
> > + <version>4.4</version>
> > + <scope>test</scope>
> > + </dependency>
> > + <dependency>
> > + <groupId>org.easymock</groupId>
> > + <artifactId>easymock</artifactId>
> > + <version>2.3</version>
> > + <scope>test</scope>
> > + </dependency>
> > + <dependency>
> > + <groupId>org.easymock</groupId>
> > + <artifactId>easymockclassextension</artifactId>
> > + <version>2.2.2</version>
> > + <scope>test</scope>
> > + </dependency>
> > + <dependency>
> > + <version>0.4.0-incubating-SNAPSHOT</version>
> > + <groupId>org.apache.abdera</groupId>
> > + <artifactId>abdera-server</artifactId>
> > + </dependency>
> > + </dependencies>
> > +</project>
> >
> > Added: incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml
> > URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml?rev=647030&view=auto
> > ==============================================================================
> > --- incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml (added)
> > +++ incubator/shindig/trunk/java/social-api/src/main/webapp/WEB-INF/web.xml Thu Apr 10 19:04:44 2008
> > @@ -0,0 +1,25 @@
> > +<?xml version="1.0"?>
> > +<!--
> > + 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.
> > +-->
> > +<!DOCTYPE web-app
> > + PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> > + "http://java.sun.com/dtd/web-app_2_3.dtd">
> > +
> > +<web-app>
> > +</web-app>
> >
> > Modified: incubator/shindig/trunk/pom.xml
> > URL: http://svn.apache.org/viewvc/incubator/shindig/trunk/pom.xml?rev=647030&r1=647029&r2=647030&view=diff
> > ==============================================================================
> > --- incubator/shindig/trunk/pom.xml (original)
> > +++ incubator/shindig/trunk/pom.xml Thu Apr 10 19:04:44 2008
> > @@ -62,6 +62,15 @@
> > <module>java/gadgets</module>
> > </modules>
> > </profile>
> > +
> > + <!-- profile to build java/rest-api -->
> > + <profile>
> > + <id>java/social-api</id>
> > + <modules>
> > + <module>java/social-api</module>
> > + </modules>
> > + </profile>
> > +
> > </profiles>
> >
> > <scm>
> >
> >
> >
>
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./ java/social-api/ java/social-api/src/ java/social-api/src/main/ java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Kevin Brown <et...@google.com>.
On Tue, Apr 15, 2008 at 2:11 AM, Cassie <do...@google.com> wrote:
> hmm.. that last bit seems a little strange. i don't know if the gadget
> renderer should be taking care of preloading social data. it seems
> like when a page renders with social gadgets on it it does two things:
The alternative here is parallel iframe trickery ala Orkut. If we're doing
http preloads in the gadget renderer anyway though, we may as well incur the
hit here for optimal performance. Naturally, this should be an optional
optimization that deployments could turn on or off depending on what makes
the most sense for their particular use case.
1. makes iframes for gadgets which hit the rendering server
> 2. makes an xhr back to the social server for social data for all of
> the gadgets at once and then shoves this data in iframes so the
> gadgets can access it.
That's a very logical solution, but it also yields poor performance in
practice. Louis and Paul probably have strong opinions on what's ideal here,
since they've both recently been discussing latency related issues. I defer
to them.
1. it seems we need a java/common package (for now i will just have
> java/social-api depend on java/gadgets)
Agreed!
> 2. we will have two entirely separate guice modules which share all
> the same guice infrastructure (?)
"Infrastructure" meaning what here? The common guice stuff I patched up to
make the servlets work? That belongs in common, if we keep it at all. I'd
prefer to eliminate it and use the standard guice provided modules, but that
requires getting an updated guice maven repo. Maybe we can bug some google
code people to publish it in the same way we did for Caja.
3. no javascript code is moving at all - just java stuff
Yes.
> 4. we'll keep the samplecontainer stuff hosted on the gadget rendering
> server for now... but it will break for java unless we do something to
> fix it.
Fine for the short term, but long term we *should* have a something that
builds a war to serve both the restful stuff and the gadget rendering stuff
on a single servlet container. That would be the most logical place to drop
the sample* pages. The artifacts produced by the other 3 components should
probably be jars, with a single top level artifact to produce the war (if
this isn't possible in maven, we'll just put a 4th dummy package for that).
> i'll proceed with the other stuff first, we'll regress a
> little, and then we'll figure it out.
>
> sound ok?
Sounds perfect to me. Thanks!
--
~Kevin
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./
java/social-api/ java/social-api/src/ java/social-api/src/main/
java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Cassie <do...@google.com>.
hmm.. that last bit seems a little strange. i don't know if the gadget
renderer should be taking care of preloading social data. it seems
like when a page renders with social gadgets on it it does two things:
1. makes iframes for gadgets which hit the rendering server
2. makes an xhr back to the social server for social data for all of
the gadgets at once and then shoves this data in iframes so the
gadgets can access it.
however, we can deal with that when we get there. for now:
1. it seems we need a java/common package (for now i will just have
java/social-api depend on java/gadgets)
2. we will have two entirely separate guice modules which share all
the same guice infrastructure (?)
3. no javascript code is moving at all - just java stuff
4. we'll keep the samplecontainer stuff hosted on the gadget rendering
server for now... but it will break for java unless we do something to
fix it. i'll proceed with the other stuff first, we'll regress a
little, and then we'll figure it out.
sound ok?
- Cassie
On Mon, Apr 14, 2008 at 11:47 PM, Kevin Brown <et...@google.com> wrote:
> On Mon, Apr 14, 2008 at 1:32 PM, Cassie <do...@google.com> wrote:
>
>>
>> Very soon - there won't be any "socialdata" stuff. There will only be
>> the restful api server. It will gloriously serve the restful apis from
>> whatever db backends someone wants to use. The opensocial javascript
>> in the features directory will use the restful wire format to get data
>> from the server and set data on the server. It will no longer use the
>> temporary json thingy that it does now (unless we utterly fail).
>>
>> The sample container will still exist (and David, its already in its
>> own root, that's not the issue - it's more about which server -serves-
>> it and the other javascript/* files). When the sample container exists
>> it will need gadgets in iframes. These iframes have to point to the
>> gadget rendering server.. and they also need to xhr back to whatever
>> server they are getting social stuff from.. thus, the need for
>> something to be able to handle that. I don't believe this shows an
>> overlap between the two servers or anything.. it just simply needs to
>> be done in order to satisfy same domain goodness.
>>
>> But hey, why do you think I put the socialdata stuff on the already
>> existing server in the first place? It is much much easier :)
>
>
> If we're completely confident that the gadget-side opensocial js code can
> talk to the RESTful servlets without modification, then I think we're
> completely covered.
>
> Running these things as a single server really isn't an issue. We can always
> provide a single war file that packages up both the RESTful stuff and the
> gadget rendering stuff and registers both gadget rendering and RESTful API
> servlets.
>
> We still need the third package though, so that the OAuth / security / other
> shared stuff has a place to live and there aren't any hard dependencies
> between them.
>
> It's also *highly* likely the gadget rendering server will need to preload
> some social data at rendering time, which means that it will need to use the
> social data interfaces (not servlets or wire format adapters or anything
> like that). I'd much rather have the gadget renderer get these interfaces
> from the common project than depend directly on the RESTful project.
>
>
> --
> ~Kevin
>
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./ java/social-api/ java/social-api/src/ java/social-api/src/main/ java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Kevin Brown <et...@google.com>.
On Mon, Apr 14, 2008 at 1:32 PM, Cassie <do...@google.com> wrote:
>
> Very soon - there won't be any "socialdata" stuff. There will only be
> the restful api server. It will gloriously serve the restful apis from
> whatever db backends someone wants to use. The opensocial javascript
> in the features directory will use the restful wire format to get data
> from the server and set data on the server. It will no longer use the
> temporary json thingy that it does now (unless we utterly fail).
>
> The sample container will still exist (and David, its already in its
> own root, that's not the issue - it's more about which server -serves-
> it and the other javascript/* files). When the sample container exists
> it will need gadgets in iframes. These iframes have to point to the
> gadget rendering server.. and they also need to xhr back to whatever
> server they are getting social stuff from.. thus, the need for
> something to be able to handle that. I don't believe this shows an
> overlap between the two servers or anything.. it just simply needs to
> be done in order to satisfy same domain goodness.
>
> But hey, why do you think I put the socialdata stuff on the already
> existing server in the first place? It is much much easier :)
If we're completely confident that the gadget-side opensocial js code can
talk to the RESTful servlets without modification, then I think we're
completely covered.
Running these things as a single server really isn't an issue. We can always
provide a single war file that packages up both the RESTful stuff and the
gadget rendering stuff and registers both gadget rendering and RESTful API
servlets.
We still need the third package though, so that the OAuth / security / other
shared stuff has a place to live and there aren't any hard dependencies
between them.
It's also *highly* likely the gadget rendering server will need to preload
some social data at rendering time, which means that it will need to use the
social data interfaces (not servlets or wire format adapters or anything
like that). I'd much rather have the gadget renderer get these interfaces
from the common project than depend directly on the RESTful project.
--
~Kevin
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./
java/social-api/ java/social-api/src/ java/social-api/src/main/
java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Cassie <do...@google.com>.
Just responding to your last comment very quickly:
On Mon, Apr 14, 2008 at 8:54 PM, Kevin Brown <et...@google.com> wrote:
> On Mon, Apr 14, 2008 at 3:07 AM, Cassie <do...@google.com> wrote:
>
>> to follow up on this change I am trying to move the social/* classes
>> out of the java/gadgets package and into java/social-api
>>
>> the social classes have the following gadgets dependencies:
>>
>> // security token stuff
>> import org.apache.shindig.gadgets.GadgetException;
>> import org.apache.shindig.gadgets.GadgetToken;
>> import org.apache.shindig.gadgets.GadgetTokenDecoder;
>
>
> These last two belong in the separate shared package, ultimately. For now,
> import the gadgets artifact.
>
> The first one should become an exception type specifically for dealing with
> the tokens.
>
> Rename to "SecurityToken" and "SecurityTokenDecoder"
>
> // guice stuff
>> import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...)
>
>
> This should actually come directly from Guice ultimately. Louis Ryan was
> attempting to figure out how to get the servlet extension for guice
> available. If we can't get it integrated soon, we'll probably move it to the
> shared project as well.
>
>
>>
>>
>> // fetching remote file stuff
>> import org.apache.shindig.gadgets.BasicRemoteContentFetcher
>
> import org.apache.shindig.gadgets.GadgetException;
>> import org.apache.shindig.gadgets.RemoteContent;
>> import org.apache.shindig.gadgets.RemoteContentFetcher;
>> import org.apache.shindig.gadgets.RemoteContentRequest;
>
>
> Shared (not rendering specific).
>
>
>>
>> Anybody have any ideas/opinions as to how we handle these things?
>>
>> Also - would people prefer that the social-api host the
>> samplecontainer, or the gadgets server? Same goes for the rest of the
>> javascript samplex.html and other files.
>
>
> Since all of these demos are rendering gadgets, they should remain packaged
> with the gadgets server.
>
>
>> The gadgets server will still
>> serve the opensocial gadget js. No matter which one we pick we are
>> going to need to do some sort of forwarding servlet or proxy thing or
>> a config of some sort which puts the gadget iframe url on the same
>> domain as the socialdata servlets so that the js can xhr. Any opinions
>> on this piece?
>
>
> I think we're conflating the opensocial js feature and the restful stuff too
> much as is. I'd prefer that the common interfaces and whatnot go into the
> shared project, while the stuff that's specific to handling the opensocial
> gadget feature be packaged with the gadget renderer and the stuff that's
> specific to handling the restful apis be packaged with the restful api
> server. I'm still not seeing what the value is in cramming all the
> socialdata stuff into the same place as the restful api server, when it's
> clearly stuff that needs to be shared between both servers.
Very soon - there won't be any "socialdata" stuff. There will only be
the restful api server. It will gloriously serve the restful apis from
whatever db backends someone wants to use. The opensocial javascript
in the features directory will use the restful wire format to get data
from the server and set data on the server. It will no longer use the
temporary json thingy that it does now (unless we utterly fail).
The sample container will still exist (and David, its already in its
own root, that's not the issue - it's more about which server -serves-
it and the other javascript/* files). When the sample container exists
it will need gadgets in iframes. These iframes have to point to the
gadget rendering server.. and they also need to xhr back to whatever
server they are getting social stuff from.. thus, the need for
something to be able to handle that. I don't believe this shows an
overlap between the two servers or anything.. it just simply needs to
be done in order to satisfy same domain goodness.
But hey, why do you think I put the socialdata stuff on the already
existing server in the first place? It is much much easier :)
- Cassie
>
>
> --
> ~Kevin
>
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./
java/social-api/ java/social-api/src/ java/social-api/src/main/
java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Cassie <do...@google.com>.
Just responding to your last comment very quickly:
On Mon, Apr 14, 2008 at 8:54 PM, Kevin Brown <et...@google.com> wrote:
> On Mon, Apr 14, 2008 at 3:07 AM, Cassie <do...@google.com> wrote:
>
>> to follow up on this change I am trying to move the social/* classes
>> out of the java/gadgets package and into java/social-api
>>
>> the social classes have the following gadgets dependencies:
>>
>> // security token stuff
>> import org.apache.shindig.gadgets.GadgetException;
>> import org.apache.shindig.gadgets.GadgetToken;
>> import org.apache.shindig.gadgets.GadgetTokenDecoder;
>
>
> These last two belong in the separate shared package, ultimately. For now,
> import the gadgets artifact.
>
> The first one should become an exception type specifically for dealing with
> the tokens.
>
> Rename to "SecurityToken" and "SecurityTokenDecoder"
>
> // guice stuff
>> import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...)
>
>
> This should actually come directly from Guice ultimately. Louis Ryan was
> attempting to figure out how to get the servlet extension for guice
> available. If we can't get it integrated soon, we'll probably move it to the
> shared project as well.
>
>
>>
>>
>> // fetching remote file stuff
>> import org.apache.shindig.gadgets.BasicRemoteContentFetcher
>
> import org.apache.shindig.gadgets.GadgetException;
>> import org.apache.shindig.gadgets.RemoteContent;
>> import org.apache.shindig.gadgets.RemoteContentFetcher;
>> import org.apache.shindig.gadgets.RemoteContentRequest;
>
>
> Shared (not rendering specific).
>
>
>>
>> Anybody have any ideas/opinions as to how we handle these things?
>>
>> Also - would people prefer that the social-api host the
>> samplecontainer, or the gadgets server? Same goes for the rest of the
>> javascript samplex.html and other files.
>
>
> Since all of these demos are rendering gadgets, they should remain packaged
> with the gadgets server.
>
>
>> The gadgets server will still
>> serve the opensocial gadget js. No matter which one we pick we are
>> going to need to do some sort of forwarding servlet or proxy thing or
>> a config of some sort which puts the gadget iframe url on the same
>> domain as the socialdata servlets so that the js can xhr. Any opinions
>> on this piece?
>
>
> I think we're conflating the opensocial js feature and the restful stuff too
> much as is. I'd prefer that the common interfaces and whatnot go into the
> shared project, while the stuff that's specific to handling the opensocial
> gadget feature be packaged with the gadget renderer and the stuff that's
> specific to handling the restful apis be packaged with the restful api
> server. I'm still not seeing what the value is in cramming all the
> socialdata stuff into the same place as the restful api server, when it's
> clearly stuff that needs to be shared between both servers.
Very soon - there won't be any "socialdata" stuff. There will only be
the restful api server. It will gloriously serve the restful apis from
whatever db backends someone wants to use. The opensocial javascript
in the features directory will use the restful wire format to get data
from the server and set data on the server. It will no longer use the
temporary json thingy that it does now (unless we utterly fail).
The sample container will still exist (and David, its already in its
own root, that's not the issue - it's more about which server -serves-
it and the other javascript/* files). When the sample container exists
it will need gadgets in iframes. These iframes have to point to the
gadget rendering server.. and they also need to xhr back to whatever
server they are getting social stuff from.. thus, the need for
something to be able to handle that. I don't believe this shows an
overlap between the two servers or anything.. it just simply needs to
be done in order to satisfy same domain goodness.
But hey, why do you think I put the socialdata stuff on the already
existing server in the first place? It is much much easier :)
- Cassie
>
>
> --
> ~Kevin
>
Re: svn commit: r647030 - in /incubator/shindig/trunk: ./ java/social-api/ java/social-api/src/ java/social-api/src/main/ java/social-api/src/main/webapp/ java/social-api/src/main/webapp/WEB-INF/
Posted by Kevin Brown <et...@google.com>.
On Mon, Apr 14, 2008 at 3:07 AM, Cassie <do...@google.com> wrote:
> to follow up on this change I am trying to move the social/* classes
> out of the java/gadgets package and into java/social-api
>
> the social classes have the following gadgets dependencies:
>
> // security token stuff
> import org.apache.shindig.gadgets.GadgetException;
> import org.apache.shindig.gadgets.GadgetToken;
> import org.apache.shindig.gadgets.GadgetTokenDecoder;
These last two belong in the separate shared package, ultimately. For now,
import the gadgets artifact.
The first one should become an exception type specifically for dealing with
the tokens.
Rename to "SecurityToken" and "SecurityTokenDecoder"
// guice stuff
> import org.apache.shindig.gadgets.http.InjectedServlet; (and friends...)
This should actually come directly from Guice ultimately. Louis Ryan was
attempting to figure out how to get the servlet extension for guice
available. If we can't get it integrated soon, we'll probably move it to the
shared project as well.
>
>
> // fetching remote file stuff
> import org.apache.shindig.gadgets.BasicRemoteContentFetcher
import org.apache.shindig.gadgets.GadgetException;
> import org.apache.shindig.gadgets.RemoteContent;
> import org.apache.shindig.gadgets.RemoteContentFetcher;
> import org.apache.shindig.gadgets.RemoteContentRequest;
Shared (not rendering specific).
>
> Anybody have any ideas/opinions as to how we handle these things?
>
> Also - would people prefer that the social-api host the
> samplecontainer, or the gadgets server? Same goes for the rest of the
> javascript samplex.html and other files.
Since all of these demos are rendering gadgets, they should remain packaged
with the gadgets server.
> The gadgets server will still
> serve the opensocial gadget js. No matter which one we pick we are
> going to need to do some sort of forwarding servlet or proxy thing or
> a config of some sort which puts the gadget iframe url on the same
> domain as the socialdata servlets so that the js can xhr. Any opinions
> on this piece?
I think we're conflating the opensocial js feature and the restful stuff too
much as is. I'd prefer that the common interfaces and whatnot go into the
shared project, while the stuff that's specific to handling the opensocial
gadget feature be packaged with the gadget renderer and the stuff that's
specific to handling the restful apis be packaged with the restful api
server. I'm still not seeing what the value is in cramming all the
socialdata stuff into the same place as the restful api server, when it's
clearly stuff that needs to be shared between both servers.
--
~Kevin