I'm sorry Chris but I didn't quite catch the difference between what goes under /social and what goes under /rest..
Long term there would only be one server/code directory for serving social data. This would be the restful api server. Then, the javascript part of opensocial would talk restful wire format to that server. So, why do we need two directories when its all going to be the same thing? (I'm probably just missing something) Thanks. - Cassie On Thu, Apr 3, 2008 at 12:44 PM, Chris Chabot <[EMAIL PROTECTED]> wrote: > I'm glad to see this thread surface again, it didn't leave me with a > satisfied feeling last time to have to hack the 'social' part into the > 'gadget' tree, my thinking on it has been mirrored by a lot of posts > here already so i won't go and repeat my self or others. > > But to bring this back into practicality for the PHP part of shindig, > from this response i see that your still proposing 2 URL entry points > right? aka: > /gadgets/(.*) > /rest/(.*) > > Which, while it'll be great that the logical source will be split out, > doesn't help me on the PHP side of things of having to mix logically > different functions: > 1) Rendering a XML file into a HTML gadget, and > 2) Serving social data to a gadget > > Where 1 and 2 could be completely different products even using > different languages, as long as the wire format is compatible (and the > goal is that this would instance be the case for the the java and php > shindig versions). This gives some flexibility to, again as example, > integrate the social data service directly on your data source (using > the PHP version) while using the Java version to render gadgets.. > > While it is indeed possible to make a gadget+social interface server, > and hope that everyone will want to make a RPC (xml rpc, soap, json, > etc) service following the API of the social interface ... in practise > this probably isn't true, and even on this list the dev's frequently use > the example of "Implement some kind of social data source into the > gadget/social server.." so sometimes implying that putting the data hook > directly into the shindig code structure and not through an external RPC > mechanism is a good thing :) > > It would really help me so much on the PHP side of things, and would > feel just a lot more like the proper approach if we could have 3 > different entry points (aka 3 servers in java slang?): > /gadgets/(.*) > /social/(.*) > /rest/(.*) > > This would (at least in my case) mean i would have 4 code directories: > /php/gadgets > /php/social > /php/rest > /php/common > > This would make my code a whole lot cleaner, be more logical for an > outsider to understand, easier to deploy separately and a lot easier to > maintain too.. And all the while it doesn't break the original scenario > where the 'social' part of it just RPC's the data from a different > location, it however does add the flexibility to make a choice per > deployment which components and infrastructure works for you. > > -- Chris > > > > On Thu, 2008-04-03 at 02:48 -0700, Kevin Brown wrote: > > > > > > > I think that ultimately there are 2 servers and 3 projects (aside > > from the > > container page itself, of course): > > > > - Server A / Project A The gadget renderer, which *includes* > > connections for > > the opensocial javascript APIs, even if they're little more than > > delegation > > to an RPC channel. > > > > - Server B / Project B The data server, which should probably include > > the > > RESTful wire format. > > > > - Project C: Common stuff. OAuth stuff belongs here as well. This > > isn't a > > standalone server, it's common code used by both the gadget rendering > > server > > and the social API server. Recycling the JSON RESTful binding for use > > in > > both the gadget server and the API server would be awesome, but it > > isn't a > > strict requirement. > > > > Everything except the most trivial deployments is going to want that > > separation. If you want 1 command to kick off both servers, that's > > what we > > have shell scripts for (maven can probably do this anyway though). > > > > One monolithic server will be a nightmare to maintain, and it makes > > little > > sense in a real world production scenario. >
