The default container config file now has a flag "impl" which selects which implementation to use. The default is set to "rpc" currently so it will still need to be altered in PHP to use "rest" instead. I dont have a good way of testing the Rest variant in Java which is why I made rpc the default. For the PHP code we would need to do one of the following - Emit a JS snippet that does config["opensocial-0.8"].impl = "rest" inline in the rendered gadget - fork the config file until we converge again
I don't feel qualified to make either of those changes in PHP land. If no one has time to do any of the above Ill fork the config for the Java code and make the default "rest". Another option would be to have the different implementations emit some version and platform information and have the config file read it and branch appropriately which maybe a useful feature to have in our pocket whenever this situation arises again.. Thoughts? On Fri, Aug 22, 2008 at 9:28 AM, Louis Ryan <[EMAIL PROTECTED]> wrote: > Getting ahead of myself obviously. Patch coming now... > > On Fri, Aug 22, 2008 at 5:21 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > >> Hey Louis, >> >> Before you committed the java json-rpc implementation we had a quick gtalk >> where I indicated that unfortunately while switching jobs i might be a bit >> restricted on time, so while i'll do my best to catch up with the json-rpc >> changes asap, i can't guarantee it will be done quickly enough to prevent >> any headaches if stuff was broken, that's why i asked for a config flag + >> working old (plain rest or old custom rpc method) to be in place until i >> would have the time to catch up. >> >> Now when i do a clean checkout however, none of the social calls work any >> more since they default to the 'new json-rpc- style interface' (which php >> shindig doesn't have yet), and there are no obvious configuration keys in >> config/container.js either. >> >> I applaud your enthusiasm to try to make some progress, but this has left >> us in the situation that anyone checking out php shindig now, gets nothing >> but a broken environment, without any documentation on how to solve this or >> (apparent) configuration options that make things work again. >> >> Previously (while working on REST for instance), we always made sure the >> default out of the box experience would work for both implementations, and >> have a config switch in place to check the shiny new code, that way things >> could be tested and developed, and at the same time make sure that no one >> was hindered by the development work. >> >> There's about 6 social networks sites currently working on integrating php >> shindig into their SNS, with an reach of ~ 82 million registered users, 3 >> live php shindig sites with ~ 78 mil registered users.. and i would much >> prefer to keep being able to offer them a working system; Next to that >> there's also some blog posts online now about php shindig and partuza, which >> hopefully could lead a few new interested people; And the upcoming GDD's in >> europe where i'd also like to show people a working system ... >> >> So I think the impact of breaking what was a well working system, is quite >> large and potentially extends out to a relatively large segment of the open >> social world, and how people will perceive shindig as a project. >> >> Could you please by any chance change the default container to the restful >> one for now (which used to work before we implemented the custom json rpc >> mechanism, needs double checking though), and add a config flag that allows >> those who want to use it to switch over to the json-rpc interface/container >> code? That way we have a clean upgrade path, and no broken installations & >> everything that comes with that. >> >> Thanks in advance! >> >> -- Chris >> > >
