To my mind, the goal of this project isn't to replace Django's routing infrastructure - as Josh and Florian have pointed out, unless you can provide a backwards compatible interface as well as tangible API improvements, we're unlikely to adopt that code.
However, there *would* be benefit in making changes to Django's codebase so that if someone *wanted* to use an alternate routing infrastructure, they could, *in their own project*. In this context, the purpose of using webOb/werkzeug routing isn't to provide new features or backwards compatibility - it's to demonstrate that a completely alien codebase with analogous features can be integrated into Django's infrastructure using a standardised API. That said, I don't know enough about webOb or werkzeug to know if this is even plausible, so you'd need to provide a very strong technical proposal for this to be selected as a GSoC project. Yours, Russ Magee %-) On Sun, Feb 22, 2015 at 8:04 AM, Josh Smeaton <josh.smea...@gmail.com> wrote: > To expand on Florians reply, why do you think replacing the routing > infrastructure is a good idea? Is there any tangible benefit in doing so? > Can you demonstrate that you can stay completely backwards compatible while > realising those benefits? If there answer is no to benefits or backwards > compatibility, then I don't think you're going to see much support for the > idea. > > Regards, > > > On Sunday, 22 February 2015 07:52:49 UTC+11, Florian Apolloner wrote: >> >> Hi Aisf, >> >> while it theoretically would be possible to replace all of Django's >> request/response handling with Werkzeug, there is not much gain in it >> currently -- especially when considering backwards compatibility etc… >> >> Cheers, >> Florian >> >> On Saturday, February 21, 2015 at 9:14:27 PM UTC+1, Asif Saifuddin wrote: >>> >>> Hi, >>> >>> Analyzing django code base docs and other tools I'm thinking of using >>> werkzeug's routing infrastructure for developing django's one. django http >>> mechanism can e re written using webOb/werkzeugs utilities too. this will >>> need working django urlresolve, urls, middlewares, views, http and some >>> more related components. Introducinf werkzeug/+webOb in django will let >>> eliminate some of django's built in way of handling request/response >>> processing, urlresolving, url routing, view processing some error handling >>> etc. >>> >>> Sould I go for a detail one with what I have thought to implement till >>> now? >>> >>> ./auvipy >>> >>> On Wed, Feb 4, 2015 at 5:57 AM, Russell Keith-Magee < >>> rus...@keith-magee.com> wrote: >>> >>>> >>>> On Wed, Feb 4, 2015 at 1:49 AM, Asif Saifuddin <auv...@gmail.com> >>>> wrote: >>>> >>>>> Thank you both for the feedback. I will continue my analysis to >>>>> understand django well and also try to contribute some patch on django if >>>>> I >>>>> can. >>>>> >>>>> >>>>> For django URL dispatcher improvement I am also looking for some >>>>> suggestions. Should I also look to some tool like werkzeug, webob along >>>>> side django http, url dispatch, middleware and related stuffs. Some guide >>>>> will help me to dig more and go to proper direction. >>>>> >>>> >>>> Take inspiration from wherever you can. Those patches will demonstrate >>>> different ways of doing dispatch, and different ways to organize a stack; >>>> in an ideal world, you should be able to use any of those techniques in >>>> Django as well. If you can find a way to modify Django so that those >>>> techniques can be used (either by directly using a third party package, or >>>> by building a Django equivalent), then I'd say you've cracked the core of >>>> the project. >>>> >>>> Yours, >>>> Russ Magee %-) >>>> >>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>>> topic/django-developers/WF3My-cZNtY/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> django-develop...@googlegroups.com. >>>> To post to this group, send email to django-d...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/django-developers/CAJxq84_XbuDCeX5LHgP4%2BuCYdzBAUUMY4EJxYj8WU% >>>> 3DBP43onXA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-developers/CAJxq84_XbuDCeX5LHgP4%2BuCYdzBAUUMY4EJxYj8WU%3DBP43onXA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/c35b86be-cba9-4d66-8e8b-fb5fcb7cf92a%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/c35b86be-cba9-4d66-8e8b-fb5fcb7cf92a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_tfCxFPG3fTY%2BNWcAcWV1tjv4VwE%2BvmWiKTsnTyPLAcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
