On Mon, Aug 11, 2008 at 12:50 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > Not necessarily. As we learned with REST, validating the spec within the > reference implementation is a very useful exercise to go through before > voting in a standard. > > I'd rather have shindig eat the pain of upgrading than live with a crappy > spec.
Funny you should mention that trade-off. I've just sent a proposal to the spec mailing list: http://groups.google.com/group/opensocial-and-gadgets-spec/msg/4f65d43e0446abbc. I don't think it would be a good idea to make the proposal a part of the opensocial spec until we've got a working implementation, preferably backed by one or more social containers saying "wow, that's compelling, we're investing time to make it work for us." Implementing this in Shindig would mean replacing most of the signed fetch code with the OAuth equivalent (though of course in a backward compatible fashion.) That's potentially disruptive, but it has some compelling advantages. In particular, it leads directly to support for HMAC signatures in signed fetch. Non-Shindig containers have that already, so having it in Shindig would be nice. To summarize the pros: - we get HMAC sigs in signed fetch - we reduce code duplication - we probably get social containers to deploy full OAuth To summarize the cons: - anyone deploying Shindig w/ signed fetch needs to sync up with the changes. I don't think this will be too painful, but it will mean keeping up with changes as they happen. Thoughts on this? Cheers, Brian
