When should we remove the java social json wire format code?

[Cassie <do...@apache.org>]

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

Re: When should we remove the java social json wire format code?

[Santiago Gala <sa...@gmail.com>]

El mar, 27-05-2008 a las 13:23 +0200, Cassie escribió:

(...)
> 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?

I guess some sort of build time modification on deployment could change
the code (sed scripts are typical to do this if no maven is involved, I
remember ant has some task that copies with some regex substitution. I
guess path -> /social/rest should be also changed for java.

Regards
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: When should we remove the java social json wire format code?

[John Hjelmstad <fa...@google.com>]

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 <do...@google.com> wrote:
On Tue, May 27, 2008 at 1:38 PM, Paul Lindner <pl...@hi5.com> 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
> plindner@hi5.com
>
>
>
>

Re: When should we remove the java social json wire format code?

[Cassie <do...@google.com>]

On Tue, May 27, 2008 at 1:38 PM, Paul Lindner <pl...@hi5.com> 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
> plindner@hi5.com
>
>
>
>

Re: When should we remove the java social json wire format code?

[Paul Lindner <pl...@hi5.com>]

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?

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.

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
plindner@hi5.com

Re: When should we remove the java social json wire format code?

[Cassie <do...@apache.org>]

Yes, update app data is important and it will be finished soon. I'm
just sending out this email early to get the discussion going. Also,
if no one was relying the json java code then it wouldn't matter if
restful is completely done or not. (which isn't true because of Paul's
email - just hypothetical)

- Cassie


On Tue, May 27, 2008 at 1:40 PM, Alejandro Rivero <al...@gmail.com> wrote:
> 2008/5/27 Cassie <do...@apache.org>:
>> 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.
>
> But "update app data" is important, as it is the way to store User
> Options from the gadgets, isnt it? Or does the common gadget data use
> a different way?
>

Re: When should we remove the java social json wire format code?

[Alejandro Rivero <al...@gmail.com>]

2008/5/27 Cassie <do...@apache.org>:
> 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.

But "update app data" is important, as it is the way to store User
Options from the gadgets, isnt it? Or does the common gadget data use
a different way?