On Wed, Apr 2, 2008 at 6:08 PM, David Primmer <[EMAIL PROTECTED]> wrote:
> Hi Cassie, I'm looking out for the API server and was under the > assumption that it would be an autonomous server. After looking at the > changes to the source tree recently (moving from the proposed > /java/social to under /java/gadgets/../social/ it seems that a few > small things have been done to make the API server more dependent on > the gadget server. Maybe this is just a matter of expediency and was > done simply to get a stub checked in to work with. But the concerns of > the PHP dev here are basically my concerns: Java build and deployment > decisions affecting the 'standard' way of doing things. > > comments below: > > On Tue, Mar 18, 2008 at 8:46 AM, Cassie <[EMAIL PROTECTED]> wrote: > > My thoughts: > > > > 1. We should make the php stuff use the same url structure as the java > stuff > > (making people change configs by hand is evil) > > 2. The java social/* directory depends on the gadgets/* directory. > > Can you explain why this is. This seems wrong to me. > > > 3. I don't care what the url is at all, as long as people only have to > run > > one server by default for the java stuff. > > There are two servers that have not dependencies on one another and > they can be mounted at their own urls or on run on different servers. > I'm a little confused about the need to get a nice 'all in one' > reference implementation server for all of OpenSocial and how it > balances against the need to provide an implementation that is > designed to be deployed in a realistic server environment. The server > as it is now can be dis-assembled and distributed but seems like this > dis-assembly could be facilitated be taking some measures to isolate > the components and add more hooks for application servers. > > > > > Okay, so all of those mean that we either need to make the > > gadgets/socialdata url work for php or we need to make the /socialdata > url > > for for java. > > > > Unfortunately, for the java side things work like this: > > - the entire running server is mapped to localhost:8080/gadgets. > > - each servlet has a namespace under /gadgets. so the GadgetDataServlet > > happens to be mapped to socialdata just like the JsServlet is mapped to > js > > and the RpcServlet is mapped to metadata. so social data is at the same > > level as all the other servlets > > This doesn't seem necessary. The social data (the API server for > people, activities and appdata) is not functionally at the same level > as these other servlets because it is not an interface for the gadget > server. You don't need to serve gadgets to participate in OpenSocial. Yes you do. You can't support opensocial without supporting the gadgets spec as well. They're effectively a single spec, although there's currently a pedantic separation due to the way that the specs have evolved. > > > - i don't think i can get out from under the gadgets namespace unless > we a) > > get rid of the namespace altogether or b) start up two servers. both of > > those don't sound so hot. > > I don't see what's wrong with a or b. Where is it specified that all > servers must start with a /gadgets/ url prefix? > > > > > On the php side, i didn't quite get why the socialdata servlet can't > live > > under the gadgets namespace (sorry for my naivete!) > > Can we just have php/gadgets/index.php handle the socialdata calls? > Perhaps > > it would help if we changed the name from "socialdata" to "gadgetdata". > Or > > just "data"? > > I'd hope that people could mix up the runtimes that are serving > different parts the /gadgets and /social system but the spec will be > fairly clear so that there are consistent url patterns across the > servers implemented at different OpenSocial sites. > > > > > If you look in the social directory it actually doesn't have to be just > > social stuff anymore. It can handle any json request to the server for > data. > > In fact, all the state file calls are handled in addition to the > > specifically opensocial type of calls. That is why their is now a > specific > > opensocial subdirectory. And, if a different gadget feature needed data > from > > the server then this setup would be reused. > > > > Alright, so, I'm up for anything that works! > > Let me know if you understood what I wrote and hopefully we can find an > > answer. > > > > Thanks. > > > > - Cassie > > > > > > > > > > On Tue, Mar 18, 2008 at 4:30 PM, Chris Chabot <[EMAIL PROTECTED]> > wrote: > > > > > Hey Cassie (I believe your the main author of the social part of > shindig > > > at the moment?), > > > > > > I'm getting started on adding some social to the PHP part too, and > while > > > looking at the current work and examples i see that it currently uses > > > the following url: > > > http://<host>/gadgets/socialdata > > > > > > While you can keep your folders nicely separated in the Java version, > > > this is more difficult to do in the PHP version (since this URL would > > > imply the social data part should atleast partially reside in the > > > gadgets folder), which creates a dependency and mixing of sources i > > > would rather prevent. > > > > > > Now i could probably bypass this by some .htaccess magic and redirect > > > the requests based on the URL to the right PHP source folder, but > that > > > would make it less readable and less intuitive for anyone looking at > the > > > PHP source (you would expect /gadgets/* to go to > > > <shindig_root>/php/gadgets/index.php and forinstance /social/* to go > to > > > <shindig_root>/social/index.php). > > > > > > Now it's my intention to keep the PHP version identical to the Java > > > version in every way possible as far as the examples and basic file > > > usage goes (features, synd config, urls etc), so this would present a > > > bit of a dilemma for me, do i create some (relatively ugly) hacks to > > > make it work with the /gadgets/socialdata or do i break away from the > > > standard url config and hope that people read the documentation well > > > enough to see what they should change to make the PHP version work? > > > > > > So my hope is we can bypass this by putting the GadgetDataServlet > under > > > a different url (/social/data? or /socialdata/<something> ? or even > > > just /social[data] ?), would help me a lot :) > > > > > > -- Chris > > > > > > -- ~Kevin
