Thanks Paul!
I'll go and remove the GadgetDataServlet based code tomorrow and flip
the switch in the default container.js to useRest : true.
So consider the 8 hour notice guys :)
-- Chris
On Jul 17, 2008, at 1:52 AM, Paul Lindner wrote:
https://svn.apache.org/repos/asf/incubator/shindig/branches/reTIRED
is now created. Feel safe in ripping code out.
On Jul 16, 2008, at 1:53 PM, Kevin Brown wrote:
We could call it reTIRED; get rid of TIRED by using REST.
On Wed, Jul 16, 2008 at 1:16 PM, Louis Ryan <[EMAIL PROTECTED]> wrote:
+1 on retiring.
Anyone still using that code care to suggest a name as it will
likely be
most relevant to them.
On Wed, Jul 16, 2008 at 1:06 PM, Chris Chabot <[EMAIL PROTECTED]>
wrote:
+1 on retiring the old GadgetDataServlet code.
It's been a pain in the backside to see features being added to one
back-end or the other, and it was confusing contributers too; My
fingers
have been itching to be able to make that move, but the java
situation
meant
we needed to wait a bit longer before we could do that because it
seemed
better to time it together w the java version.
In essence doing a mini release or telling people to use revision
XXXXX
is
the same really, just a snapshot in time; But without being able
to fix
things like you could on a branch... so branching has my vote.
This will put some strain on people who are developing using the
latest
version of shindig, but that chose to stick to the old wire
format for
now
(i know of a few of those) but i guess they need to switch over
at some
point anyhow to get 0.8 support, so what better time then the
present
right?
:)
How's other committers feeling about this? As far as i'm
concerned sooner
is better then later :)
-- Chris
On Jul 16, 2008, at 7:59 PM, Cassie wrote:
Now that we've decided on a path for the restful java code it's
time to
figure out how we are going to deprecate the non-rest old code.
(ie
GadgetDataServlet and friends). I know people are using the old
code in
prod
so it needs to live somewhere and I'm not sure what the proper
thing to
do
in svn is.
- do we branch in svn and put the old code on the branch? (i
think the
new
rest code should definitely be in "main")
- do we just tell people to stay at revision xxx if they want it?
- do we do a mini-release?
It is probably something else I haven't thought of at all. And
php guys
-
you will probably have to do this too, so we should probably
share the
same
decision.
Thanks again for all feedback.
- Cassie
ps - just think, we almost have a clean social-api codebase!
Paul Lindner
[EMAIL PROTECTED]
