Allow context processors access to current version of context
Hi! I have opened a ticket and would like some feedback on it. Do you think it is a good idea? Ticket description: Allow context processors access to current version of context so that they can change values and not just override them. This can be easily done with another argument, context, and also backwards compatible. Functions would only get additional argument if they are defined to get two arguments and whatever they would return would override that in the context. http://code.djangoproject.com/ticket/13841 Mitar -- 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.
Re: MOSS Award to Django
Hi! This is really awesome news! Can I suggest to use WebRTC data channel instead of Websockets? I think we should make a paradigm shift and move to use WebRTC instead of Websockets. This allows many interesting properties: * connections can be based on SCTP * have multi-path routing * you can have data packets which are reliable or unreliable * you can even have backpressure support (imagine that you could push back on Meteor publish because client cannot handle observes as quickly as server is pushing) There is a great open source project already available which provides both client server suppor: https://github.com/feross/simple-peer Some interesting links to read: * https://github.com/webrtcftw/goals/issues/1 * https://github.com/jbenet/random-ideas/issues/13 I opened a ticket as well: https://github.com/andrewgodwin/channels/issues/38 Mitar On Fri, Dec 11, 2015 at 10:18 AM, Andrew Godwin wrote: > Hi everyone, > > For those who haven't seen, Mozilla has awarded $150,000 to Django for work > on Channels and request/response improvements lifted from REST Framework. > More in the blog post here: > https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/ > > I'll be coordinating this effort for the most part, but we're still working > out who to fund and the roadmap for the project, as well as work out how we > can pay people for their work on a different scale to the Django Fellowship, > so it might take a bit of time! > > I'll be back on here with some questions for people to discuss/answer about > the channels design at some point soon, but a lot of the basic design is > already up at http://channels.readthedocs.org, so take a read over that if > you're interested. > > What I can say is that my intention is to both bake Channels into the next > major release of Django, as well as hopefully release a pluggable app > version that will run on 1.8 and 1.9 - I have some plans around how to do > that effectively, but they involve hitherto unforged paths around Django and > how we package dependencies, so I can't say we'll get there 100%. > > Andrew > > -- > 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/CAFwN1upjXf2LLk2gGA9mzdPQn4DbWehSHNFWhF-GkEk4q54gHA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKLmikNtJhHQntNaSWvyeiz4qhVunM4OZ%2BJM-9v4VpuArmfsdQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: MOSS Award to Django
Hi! On Sat, Dec 12, 2015 at 6:29 AM, Aymeric Augustin wrote: > Unless I missed something, channels aren’t about websockets. They add > asynchronous processing capabilities to Django. They aim at being compatible > with any bidirectional protocol. Yes, but currently, that "bidirectional protocol" is "bidirectional protocol without backpressure" which makes it really useless in any serious production use with scaling. It is interesting for smaller toy use cases, but without backpressure you simply cannot handle congestion and your systems blow in your user's face. node.js has learned this the hard way by reimplementing their streaming API multiple times. What I would propose is that Django officially exposes channels API with backpressure and then for simpler projects (or one where you do not care about delivery) one can use Websockets, but otherwise for production use for heavy loads WebRTC data channels with backpressure should be provided. > At this point, I’m not convinced that simple-peer is sufficiently mainstream > to be the recommended solution for Django websites. No, that is just an example of the node.js module which provides server-side WebRTC support. And yes, this is something which is cutting edge. I would be completely OK by supporting Websockets now on the transport level, but the API level should understand and support backpressure. Otherwise we will have issues in the future once this feature gets widely deployed and started using in production. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKLmikPjYgB3LUsSrDvxQ20rtopAU21meC6xNLRRjcx1y%3DY76Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Self-referenced template recursion handling
Hi! I just discovered this thread on the mailing list. I implemented also template recursion in this modified django-overextends: https://github.com/wlanslovenija/django-overextends/blob/nested-extends/overextends/templatetags/overextends_tags.py It supports all possible combinations. For example, not just "base.html" extending "base.html", but also "user.hml" extending "base.html" which extends "base.html" (example: https://github.com/mitar/overextends-test). In fact, it allows arbitrary nesting and combinations. It works by keeping a list of possible sources for each template and as template is rendered it removes it from the list, so that next time it is not loaded anymore. Currently it is implemented as a custom tag and monkey-patches Django to provide template origin to tokens also when TEMPLATE_DEBUG is false. See https://code.djangoproject.com/ticket/17199#comment:9 Comments band benchmarks are welcome. Mitar On Thu, Dec 12, 2013 at 12:33 AM, unai wrote: > Hi there! > >> I'm working on an other solution that instead of relying on loader >> skipping relies on template skipping. > > Sorry for keeping you waiting on updates for so long! > > I was able to put some time into it today. Although it isn't nothing > definitive and testing, benchmarking and docs are missing, here is some actual > code for you to look at: > > https://github.com/unaizalakain/django/compare/template_selfreference > > You can totally ignore the testing commit. The loaders commit per se is > relatively small and the idea behind it is quite simple. As you already know, > any critic, suggestion or idea is highly appreciated ;-) > > I'm going to be able to put some more effort into this tomorrow. > > Best regards, > > Unai Zalakain -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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 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/CAKLmikMScJoj_Z%2BGM6PAPNQ_UVoG9xcT_C5dWOKQwtmbxwHMQg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
