Are the changes so deep that you couldn't propose them as changes for the existing oauth lib or as another jar that sits along-side the existing code? Also what about oauth-signpost? Might those contributions find a home there?
http://code.google.com/p/oauth-signpost/ On Wed, Jun 24, 2009 at 12:04 PM, Kevin Brown <e...@google.com> wrote: > Hi everybody, > > I've been thinking a lot recently about taking the patterns that we've > layered on top of the oauth consumer code in shindig and forming them into > something that can be used as a standalone library. The concepts here have > broad applicability beyond opensocial, and ultimately I think that what > we've done can form the basis of an alternative to the existing net.oauth > package. The existing code can't quite be used as it stands, because it > makes a lot of assumptions based on opensocial that don't always map well > to > things that aren't opensocial. > > I figure that there are a couple of ways to go about doing this: > > - Spin off a sub-project, keep things within shindig > - Create a new project, and maybe have shindig depend on it in the future. > > The former has the advantage of brand recognition and an existing > community, > but the disadvantage of information overload (if all you care about is > oauth, you don't need to understand opensocial). The latter can be tightly > focused, but it would also be 'new' and hence less trustworthy. > > Before I go off and do anything though, I wanted to know how other people > are using oauth as consumers, and whether a library that deals with the > complexities of token and key management, as well as all of the extensions > that we support, would be valuable. > > Is anyone else using the shindig oauth code for non-opensocial things? What > do you like / dislike about it? > Is anyone else using some other loauth library for non-opensocial things? > What do you like / dislike about it? >
