Hi Andrew, On 12/17/2015 04:34 AM, Andrew Godwin wrote: > Hi everyone, > > One of the first steps I want to get done for Channels is get a rough > plan in place for how things are going to work in terms of where code > goes, supported versions, etc. I've written up my thoughts on this into > a first draft of what I'm calling the "integration plan": > > http://channels.readthedocs.org/en/latest/integration-plan.html > > Feedback is much welcomed - I'd particularly like to hear people's > thoughts on the ideas of releasing both natively in Django 1.10 and as a > third-party addon for 1.8/1.9, plus the new (for Django) concept of > releasing part of it as a separate codebase, though still under the > Django umbrella.
Thanks for your work on this. A few quick thoughts on first reading: - On the packaging side, we don't really support or offer instructions for any installation technique other than pip -- even if you manually download a tarball, you should still install it with pip. Even our "install the dev version from git" instructions use "pip install -e .". So I think you should simplify the packaging/code-reuse plan to "interface server and channel backends will be separate packages, listed as dependencies where needed." AFAIK we've said for a while now that we're ready for required dependencies, just waiting for a case where we actually need them. I think this is that case, and it's a better option than adding a bunch of build complexity where sometimes things are bundled and sometimes they are not. - I share Mark's concern about the performance (latency, specifically) implications for projects that want to keep deploying old-style, given all the new serialization that would now be in the request path. I think some further discussion of this, with real benchmark numbers to refer to, is a prerequisite to considering Channels as a candidate for Django 1.10. To take a parallel from Python, Guido has always said that he won't consider removing the GIL unless it can be done without penalizing single-threaded code. If you think a different approach makes sense here (that is, that it's OK to penalize the simple cases in order to facilitate the less-simple ones), can you explain your reasons for that position? - Re imports and builtin vs third-party, I think we should avoid magic and just require try/except for portable code. It's a bit of boilerplate, but only authors of reusable apps are likely to need it, and it keeps things simple and explicit. The boilerplate can be easily packaged up in a `compat` module if someone cares enough. - I also share Mark's concern about the SCRIPT_NAME change. Non-root deploys are a key use case for many people (and a lot of work over the years has gone into making them work!). I don't think it's an option to just shrug and break that entirely in Django 1.10, which is what it currently sounds like you're proposing. What's the technical obstacle here, exactly? Carl -- 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/5672E7C3.1000704%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
