Worth the effort, right? =), i think its a good way to look forward to the new version =)
G.- On Thu, Aug 14, 2008 at 4:44 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > If existing (RSA) signed fetch continues to work, it's probably fine. > Breaking that would break many social gadgets. > > On Wed, Aug 13, 2008 at 11:31 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > 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 > > >
