On Wed, Mar 31, 2010 at 2:09 AM, d3f3nd3r <d3f3n...@bytegeist.org> wrote: > >> Well.. how about you tell me whether you're going to pursue the >> project before I spend a bunch of time giving feedback when you don't >> actually want it? >> >> As a top sheet summary - To be brutally honest, I'm still not >> convinced you've got a coherent plan that would be acceptable to >> Django's trunk. If you still want to pursue this project, let me know, >> and I'll give you some more detailed feedback. >> > > Sorry for the delayed anwser, won't happen again! > > I really want this project, because I think it's an important one and > I was faced with the problems of the current framework when writing a > auth backend for Google Accounts on App Engine. Of course it's > possible to hack around the problem by adding a relation to auth.User > (done so by django-socialauth for example), but I don't think this is > the right way in an object-oriented programming language, because when > linking to a auth.User model, you carry a lot of unused stuff with you > (password and so on).
You don't need to convince me of this bit. There's a reason this has been proposed as a SoC project. > In my first email, my plan was very vauge, but I think we are heading > to a more detailed plan. I'm glad you think so. From my perspective, I think you have a clearer idea of the problems that exist, but I'm not yet convinced you have a plan that will be acceptable for inclusion in trunk. > Backward compatibility is the key issue (you were very clear about > that). As I mentioned before, adding the kind of abstract user layer I > suggested in my post would break compatibility and there are a lot of > apps out there, which won't benefit from the new layer without any > modification of the database. My plan is to provide a tool for > converting to the new more flexible system (mentioned before: dump all > users, delete old user table, create new tables, convert old user to > new user and insert into db) and keep the old User class untouched and > add a the new user class as NewUser or so (I'm thinking about > something like you have done before, for example with the newforms > system). Ok - two points here: 1) Why all the dumping and reloading? Is there something wrong with ALTER TABLE? 2) Why all the dumping and reloading? Part of the point of having a pluggable authentication system is that we *dont'* need to do a massive migration - we keep using and shipping auth.User, but provide the pluggable interface for other users to provide their own User class as required. 3) If you're going to use newforms as an analog, you need to give the full picture. We added newforms before 1.0, and when we added it, we indicated that oldforms would be deprecated before 1.0. There was a clear plan for how and when forms would become oldforms, and how newforms would become forms, and when oldforms would disappear. We introduced a best practice for the interim (from django import newforms as forms) to minimize the transition pain for users adopting newforms. If you're proposing "NewUser', what is the deprecation plan? How do we manage a transition from auth.User to auth.NewUser, so that eventually auth.NewUser becomes auth.User? How many release cycles are we going to be talking about? What happens at each of those steps. > The Django internal code has to be modified to work with both, the old > and the new system (I'm thinking about checking with isinstance and/or > a settings attribute) > You asked for more detailed information how backward compatibility > should be maintained, but I don't know what kind of information you > need/want - code examples, modules that have to be modified? I want to see some evidence that you've investigated the potential problems at a level deeper than just running grep over the source tree. Have you looked into how the User model is being used? Are there any potential complications in replacing auth.User with a new model? How will this affect users that are still using auth.OldUser? Even if there aren't any potential problems (which I find unlikely, but it is possible) -- I want to you walk me through the changes that need to be made, and try and convince me that there shouldn't be any problems. > I'm looking forward to hear your detailed comments! > I think summarizing the changes and posting the modified idea for > further discussion would be a good idea!? Yes. At this point, I'm more than a little lost over exactly what it is that you are proposing. A fresh summary would be very helpful. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
