Well... thankfully the Java stuff is still easy to separate. So, if you did want to use two servers then it wouldn't be too bad. Essentially, you would just install the servlet in some other web server somewhere (because servlets can be moved around easily) Then, you would just have to do some url mapping to have the social server live on a sub path of the gadget server (for the same-domain xhr issues)
So, it is relatively easy in java land still. (As in the java side would require small file changes as well as a url subpath setup) (I'm not sure anyone would want to do this as the interfaces in social/opensocial/*service could be handled by making remote calls to other servers, but I suppose someone might.) If you build them together in the php land is it still -relatively- easy to pull them apart? Is there any way to make it easy while still having them live as one url path in php? - Cassie On Tue, Mar 18, 2008 at 5:48 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > Well my reasoning was based on the assumption (and you know what they > say about assumptions) that these could be possible use-cases for the > PHP version, where the site its self is likely to be PHP based as well. > > The assumption being that often the social data server and the gadget > server would be run separated from each other. > > I imagined something like: > > In a medium sized setup you could have your site run on a few servers, > and already have the infrastructure in place for some type of scalable > data back-end. The easiest route to add the shindig server to this setup > would be by setting up a gadget server (or a couple of them if the scale > requires), and add the social data server on the existing site servers > (integrating it with the existing data back-end for its social > information), this way the infrastructural change would be kept to a > minimum and you would re-use it as much as possible. So you would deploy > the social data server on the existing site servers, > > In smaller scenario's where you would for instance only have one server, > you would probably want to have 3 vhost's on the same server, one for > the gadget server, one for the site and one for the social data server, > where you just deploy the source of each into a folder, add your own > back-end to the social data server, and you should be done and ready to > socialize :) > > Now the scenario your giving me for the java server is quite different > from this, it means all servers involved are both social data and gadget > server, in which case the bundling of the two is no problem of course. > So the cases i head in my head are just quite different and hence what i > expected too :) > > If we are sure we always want the social data and gadget server running > on the same domain / host / server's, then I have no problem adding the > social data to the current gadget server code in the PHP version, if > that's not the case, then we'll have to start thinking solutions :) > > -- Chris > > On Tue, 2008-03-18 at 16:46 +0100, Cassie 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. > > 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. > > > > 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 > > - 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. > > > > 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"? > > > > 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 > > > >
