Added a hard coded config["opensocial-0.8"].impl = "rest" to the
gadget renderer, should tie us over until we finish the json-rpc
interface on the php side.
Thanks for the help in getting this fixed!
-- Chris
On Aug 22, 2008, at 6:48 PM, Louis Ryan wrote:
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
