I confess I replied without context (OpenIDConsumer being sparely used in application code, if at all).
One question that comes to my mind is whether OpenIDConsumer should be regarded as api at all. If yes I would still opt not breaking api in minor releases. If not, api and non-api should be more clearly separated. Eclipse as an example uses *.internal.* as package name convention. They still make all their packages available to others but breakages in there are the consumers problems. Kind regards, Jan 2009/3/15 marius d. <[email protected]> > > +1 Charles... (... I would rather avoid diverging into a philosophical > discussion). I wonder if there is someone out there that actually used > directly OpenIDConsumer ... it's likely not break anything since > Lift's OpenID support is pretty undocumented ... till now. Furthermore > I opted in for renaming OpenIDConsumer and not OpenIdVendor because > the later is what you'd directly use to enable OpenID in your > application and there are way better chances for existing apps to > actually use OpenIdVendor already. > > Br's, > Marius > > On Mar 15, 10:46 pm, "Charles F. Munat" <[email protected]> wrote: > > I would argue the reverse. Naming consistency is forever. Breaking the > > API is once, and affects only a small number of developers. I, for one, > > when I start using OpenID, will be screwing that up over and over again > > as my brain refuses to remember which one is all caps and which is mixed > > case. > > > > Chas. > > > > Jan Lohre wrote: > > > Breaking the api IMHO needs stronger justification than naming > consistency. > > > > > But thats just my two cents. > > > > > Kind regards, > > > Jan > > > > > 2009/3/15 Marius <[email protected] <mailto: > [email protected]>> > > > > > Folks, > > > > > Writing about OpenID in LIftBook inherently made me use it so I can > > > use valid examples. Everything worked smoothly ... util I turned > off > > > cookies. This broke the OpenID flow and the Identity Provider side > > > returned an error page. There were two fundamental problems: > > > > > 1. On redirect the Location was updated encodeURL from response > > > regardless if this was an absolute URL and jsessionid part was > > > becoming part of the redirect of the Identity Provider destination > URL > > > which was obviously wrong > > > > > 2. OpenID code did not call S.encodeURL for the return_url meaning > > > that the Identity Provider was redirecting back to our site and > since > > > jsessionid part was no there it was pocessed in the context of a > new > > > session and not the correct one. > > > > > I will be committing the fix for this a a couple of minutes ... > woks > > > smooth now. But there is a minor thing. We have the traits: > > > > > OpenIdVendor and > > > OpenIDConsumer > > > > > does anyone has any objections renaming OpenIDConsumer to > > > OpenIdConsumer (for naming consistency purposes)? > > > > > Br's, > > > Marius > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
