Agreed.
On Thu, Aug 14, 2008 at 12: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 >> >
