Much though legacy code is lame to have around, it's kept for good reason. We're only talking about the Java JSON code here, which we can mark as deprecated. Maybe it's overly optimistic, but the pull of REST seems strong enough on its own to inspire transition by clients.
One idea (abstract): Refactor all these classes either in their own package labeled deprecated and/or in a single .java file so it's easier to identify as old, while cutting down on cruft spreading to and fro. --John On Tue, May 27, 2008 at 4:49 AM, Cassie <[EMAIL PROTECTED]> wrote: On Tue, May 27, 2008 at 1:38 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > Oh no?! Are you going to change the People/Data/Activity interfaces? Can > you at least propose your changes before we commit to anything? These types > of changes are really disruptive. What exactly needs changing? We will not be changing the interfaces at all without proposing modifications - so you don't have to worry about that. My proposal was for just deleting the json specific code - GadgetDataServlet, GadgetDataHandler, OpenSocialDataHandler, StateFileDataHandler, RequestItem. ResponseItem, ResponseError would stay as the interfaces use them for now. As for future changes, we would definitely have to go through everything on a separate thread. Off the top of my head I would say that the ResponseItem would be deleted and the types of methods provided by the interfaces would probably change slightly. But again - we will definitely talk about this. > > Also, there are people that have already written native code that talks to > the current socialdata mechanism. At hi5 we're going to have to go a > complete cycle with a working REST server running alongside a compatible > socialdata server. I'm not looking forward to having to maintain the large > set of patches required to make that work. So this is exactly what I wanted to know - thank you. How should we handle this within Shindig? Should we have both impls live side by side for several weeks, months, years? Should we try to come up with some easy migration instructions? How do we know when it is ok to delete the deprecated code? (ie what should our criteria for completeness be?) And when do we change useRestful to be true in svn? Because hi5 is one of our active clients it would be great to know what your thoughts are on a transition plan. (especially because you guys will need restful for 0.8) Thanks! - Cassie > > On May 27, 2008, at 4:23 AM, Cassie wrote: > >> The java restful code has been making a lot of progress lately. For >> our json output we are now handling all gets (except for full >> pagination) in accordance with the spec. You can't update app data or >> create activities yet... but creating activities isn't supported for >> the json wire format either. >> >> Today or tomorrow I should also have another patch in which changes >> the samplecontainer to use restful urls for its extra needs (setting >> and dumping state). With these changes it means that the >> SocialHelloWorld gadget is 90% functional. (we just need to get >> updating of app data and respecting the social token in) >> >> So, my question is, when can we remove the java json wire format code? >> It would clean up the social-api directory a lot to focus on only >> restful and would allow us to change the *service interfaces to better >> match restful's needs. We wouldn't remove the js code for now because >> php is still relying on it. >> >> >> Is anybody relying on the current code as well as updating their >> shindig svn frequently? Would you mind splitting from the trunk? >> If so, when would you be ready to switch to full restful support? (ie >> which features must be done) >> >> >> Also, if we do change the java to use restful as the default that >> would require changing the config/container.js file to >> useRestful=true. How can we have the java use restful by default and >> the php use the json code by default? >> >> Thanks for your thoughts! >> >> - Cassie > > Paul Lindner > [EMAIL PROTECTED] > > > >
