Hi Christian, On 28 juil. 2013, at 16:20, Christian Schmitt <[email protected]> wrote: > 1. CORS: > (…) > This is very sad and django has no current solution for this. Maybe this > would also be cool to be configured in the Django-admin
Django provides an API to set HTTP headers in responses. I don't know what higher-level abstraction would help deal with CORS, but in all cases, it's a security-related configuration. As such, it belongs in the settings, not in the admin. (In fact, it may belong in the web server configuration, not in Django; I can't say for sure!) There's at least one third party app designed to help on this front: https://pypi.python.org/pypi/django-cors-headers. If you want to bring improvements to Django in this area, you should write a concrete API proposal. You can safely assume that readers of this mailing list have good grasp of the state of the web :) > 2. OAuth/OAuth2 support: > (…) > I think it would be great to move one of them in contrib, that the > development of these great tools could be coordinated and only one or two > good solutions will stay alive while people could contribute to the 'best' > solutions. If my informations are correct, oauthlib and django-oauth-toolkit are taking the lead, at least on the OAuth2 front. Given my experience with OAuth, I'm not looking forwards to maintain an implementation in Django :/ It's a great example of a feature that can be maintained outside of Django itself. > Since its always a pain for developers to use packages when there are so > many. It leads to fragmentation. I mean what happens when i then need to > fork, since some features are missing on every package? then we have another > solution and most of the time the fork won't get pulled into the main > version, so there will be a new package alive. I understand that fragmentation causes frustration. However merging packages into Django isn't guaranteed to help. If some features are missing, it'll take much longer to add them in Django than in a third-party package. Python's standard library is where packages go to die. To a lesser extent, that's also true of django.contrib. > Currently I think that we should take a look in the future and maybe add more > packages to contrib that solves the problem of Django and the future web. I have to disagree. The ecosystem of third-party packages is much more instrumental to the success of Django than contrib apps (with the exception of the admin). Blessing a solution stifles competition, hinders progress, and makes it much harder for (possibly better) alternatives to emerge. That's why the current trend is to slim down contrib. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
