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
> >
