Why doesn't the framework provide support for translated database content?

[Bernhard Posselt]

Hi guys,

I'm running a "hobby" website with translations for roughly 83 languages
and I've taken a thorough look at the available options (as in: Django
apps):

* django-modeltranslation: probably a bad idea to create 83 columns for
each translated string

* django-hvad: never got this to work

* django-parler: basically dead, the test suite does not pass on 1.10
and 1.11 and the dev mentioned that he has no time to fix it

I've settled on django-parler at the time because it worked pretty well.
I know you want to outsource as many features as possible (so do I for
my personal projects) but the downside of that is that 3rdparty apps
that you rely on can die off pretty quickly and then you're stuck.

In this specific case I'm kinda wondering why translation is built into
Django with the exception of models. Other frameworks ship this stuff
out of the box. I know that there are different ways to implement but I
can only think of 2:

* put everything into one table

* put everything into a translations table and join the required language

So why is there no (configurable), built in support for this seemingly
basic feature?

-- 
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/da250935-e431-71cb-e3e8-57e0f4f67a3b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[James Bennett]

Because even if you collapse the number of approaches to just two general
options, there's still enough variability in the specifics of how to
implement those options that there's no clear "one size fits all" solution
at the moment. If there ever is one, it can be considered for inclusion in
Django, but right now there just isn't.

-- 
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/CAL13Cg_Ri3223JTQv5G1fPvHY7QxZiRAez%2B7GaGOAcsaxbpA2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[Bernhard Posselt]

Why not build in the most common approach while still allowing people to
override it like they do know? They could simply swap out the default
manager right?


On 06/13/2017 06:54 PM, James Bennett wrote:
> Because even if you collapse the number of approaches to just two general
> options, there's still enough variability in the specifics of how to
> implement those options that there's no clear "one size fits all" solution
> at the moment. If there ever is one, it can be considered for inclusion in
> Django, but right now there just isn't.
>

-- 
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/5d32decb-6468-21e0-0756-91fde47ab20b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[James Bennett]

Generally, I'd like to see something satisfying the needs of around 80% of
use cases out of the box before including it directly in Django. No
database-translation tool I'm aware of is even close to that level.

-- 
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/CAL13Cg8uQashOJ1z2TFbw9JSaf_JuukpEv7PgOK1xNjQnDDRiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[Bernhard Posselt]

The question is how we guess that it fits 80% of all use cases :) IMHO
80% are covered with the two approaches that I listed in the first mail.

I mean you reach the limits of the ORM pretty quickly as well but you
can always drop down to raw Sql and circumvent the built in API restrictions


On 06/13/2017 07:00 PM, James Bennett wrote:
> Generally, I'd like to see something satisfying the needs of around 80% of
> use cases out of the box before including it directly in Django. No
> database-translation tool I'm aware of is even close to that level.
>

-- 
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/5c017ab6-93ce-6f4a-b38c-2c3b2696213a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[James Bennett]

80% covered by two approaches that aren't really compatible with each other
doesn't get there :)

Again: to get into Django, something really needs to be as close as
possible to "one size fits all", not "one size fits some, another size fits
some more".

-- 
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/CAL13Cg8CGjBO--D%2Bs6mQpOU9Z0EMBSNvaCA9z%3DDU%2BhHDNNDx1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why doesn't the framework provide support for translated database content?

[Raphael Michel]

Hi Bernhard,

fyi: a similar topic was recently discussed here[0].

My point of view:

I recently counted 19 packages for this purpose, six of them being
actively maintained. You already mentioned that there are two ways that
you can design the database layout (I argue there are three, but thats
nitpicky), but there are also multiple ways to design the Python-side
API.

And here's the point: For each and every of the available options,
there are really big disadvantages.

The JOIN approach is the cleanest database-wise but has its own
problems, for example it gets really messy when you want to deal with
multiple languages at the same time. Also, no implementation managed to
implement that without massively limiting the overall power of the ORM.

The "many columns" approach is bad, because it requires migrations
every time you want to change the supported languages and because it
might lead to very large data sets returned by the database -- but its
easier to work with multiple languages at the same time.

There are also two implementations (django-nece and django-i18nfield)
using a JSON-based approach which mixes some of the problems and
features of the other two approaches, but you give up some lookup or
filterting functionality.

There is absolutely no one-size-fits-all solution here in sight, not
even a works-for-90%-of-people soltion. That makes it really hard to
argue for one of them to be included in Django.

On DjangoCon Europe this year, I gave a talk comparing the six
maintained packages [1]. In an email earlier on this list [2] you can
find a very short summary of that. Unfortunately, the videos of
this conferences are not yet online. You can find my slides at [3],
although the Slides mostly contain the mere facts, and not the opinions
expressed in the talk ;)

Cheers
Raphael

[0]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/HBj-S8ypBgAJ
[1]
https://2017.djangocon.eu/schedule/data-internationalization-in-django/
[2]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/4q7HNXysBgAJ
[3] https://speakerdeck.com/raphaelm/data-internationalization-in-django

-- 
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/20170613191025.14fade39%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgpVy13lQyhfG.pgp
Description: Digitale Signatur von OpenPGP

Re: Should contrib.auth include support for 2fa out of the box?

[m . levental]

I would like to explain a potential solution I have been working on (See 
commit https://github.com/mlevental/django/tree/ticket_25612). I think it's 
not complete but I don't have the time to continue working on it.

*Overview:*

   - In order to check if a user is authenticated with one or two factors, 
   the attributes *is_one_factor_authenticated* and 
   *is_two_factor_authenticated* were added to *AbstractBaseUser *(and 
   therefore to *AbstractUser *and *User*) and *AnonymousUser*.
   - For *AnonymousUser *both attributes are always False. For 
*AbstractBaseUser 
   is_one_factor_authenticated* is always True because an authenticated 
   user is authenticated with at least one factor, *is_two_factor_authenticated 
   *is explained in the next paragraph.
   - *is_authenticated* stays unchanged but the meaning becomes 
   "authenticated with one or two factors". This way an application can have 
   users who use 1FA and others who enabled 2FA.



   - Similar to the backends in django.contrib.auth there are backends for 
   2FA. But instead of returning a *User *object they must return a *Device 
   *object on success.
   - *Device *is a model class that encapsulates all the necessary data of 
   a 2FA method for a single user, e.g. cryptographic keys. It can but doesn't 
   have to represent a real device.
   - After a successful two factor authentication the device is stored in 
   the session. The middleware *TFAMiddleware *(which must be installed 
   after *AuthenticationMiddleware*) sets this device for the user coming 
   from the request object.
   - *is_two_factor_authenticated* of *AbstractBaseUser *evaluates to True 
   only if a device is set.



   - The authentication process is handled by two views. *FirstFactorLoginView 
   *is responsible for authenticating with the first factor and redirecting 
   to *SecondFactorLoginView *on success. *SecondFactorLoginView *handles 
   the authentication with the second factor and redirects to a defined URL on 
   success. If the user accessing the *SecondFactorLoginView* isn't 
   authenticated with the first factor he is redirected to the 
   *FirstFactorLoginView*.
   - The *SecondFactorLoginView *can have multiple forms. 
   - This is done because different 2FA methods can require different input 
  fields (e.g different input types, labels, number of input fields). 
  - Also this allows to display multiple forms, for example when it is 
  desired to show the form for the default 2FA method and the backup method 
  on one page.
  - By default *SecondFactorLoginView *loads all the forms specified in 
  the setting *TFA_FORMS*. Which forms are displayed can be adjusted in 
  the template or by overriding *get_form_classes()*. Only one form 
  gets validated on a POST request. Therefore when submitting the form the 
  2FA method name needs to be included as a HTTP POST parameter.
  - For example if the setting *TFA_FORMS* is the following:
   
TFA_FORMS = [
{'METHOD_NAME': 'TOTP', 'FORM_PATH': 
'django.contrib.twofactorauth.forms.TOTPAuthenticationForm'},
{'METHOD_NAME': 'Backup Token', 'FORM_PATH': 
'django.contrib.twofactorauth.forms.BackupTokenAuthenticationForm'},
]
   
  and the *TOTPAuthenticationForm *is submitted, then 
type=TOTP must be included, for example in a button tag:


  {% csrf_token %}
  {{ forms.TOTP.as_p }}
  {% trans 
'Submit' %}
   


   - For convenience there is the *tfa_required* decorator and the mixin 
   *TFARequiredMixin*. They work analogous to the *login_required* 
   decorator and *LoginRequiredMixin *from django.contrib.auth. Instead of 
   checking for *is_authenticated* they check for 
   *is_two_factor_authenticated*. If the user is not two factor 
   authenticated he is redirected to a specified URL.
   - For example the URL can be specified by setting *TFA_LOGIN_URL* to 
   "tfa:first_factor_login" and would point to the *FirstFactorLoginView*. 
   By default the *FirstFactorLoginView *requires the user to authenticate 
   with the first factor and redirects on success to *SecondFactorLoginView*. 
   If desired the *FirstFactorLoginView *can redirct an already one factor 
   authenticated user to *SecondFactorLoginView *right away, for this 
   *redirect_authenticated_user* needs to be set to True. After 
   successfully authenticating with the second factor the user is redirected 
   to the initially inaccessible page. For this last redirect to work the 
   redirect URL is transfered from *FirstFactorLoginView *to 
*SecondFactorLoginView 
   *by appending it as a HTTP GET parameter.



   - For the admin site to support 2FA the class *AdminSiteTFARequired *was 
   created which inherits from *AdminSite *and the new mixin 
   *AdminSiteTFARequiredMixin*. This mixin overrides *has_permission()* so 
   that admin urls can only be accessed by two factor authenticat

Re: Should contrib.auth include support for 2fa out of the box?

[m . levental]

I would like to explain a potential solution I have been working on (See 
commit 
https://github.com/mlevental/django/commit/51dbaa6748076e06d91b361c2fa60ecf24f5c27e
 
).
 
I think it's not complete but I don't have the time to continue working on 
it.

*Overview:*

   - In order to check if a user is authenticated with one or two factors, 
   the attributes *is_one_factor_authenticated* and 
   *is_two_factor_authenticated* were added to *AbstractBaseUser *(and 
   therefore to *AbstractUser *and *User*) and *AnonymousUser*.
   - For *AnonymousUser *both attributes are always False. For 
*AbstractBaseUser 
   is_one_factor_authenticated* is always True because an authenticated 
   user is authenticated with at least one factor, *is_two_factor_authenticated 
   *is explained in the next paragraph.
   - *is_authenticated* stays unchanged but the meaning becomes 
   "authenticated with one or two factors". This way an application can have 
   users who use 1FA and others who enabled 2FA.



   - Similar to the backends in django.contrib.auth there are backends for 
   2FA. But instead of returning a *User *object they must return a *Device 
   *object on success.
   - *Device *is a model class that encapsulates all the necessary data of 
   a 2FA method for a single user, e.g. cryptographic keys. It can but doesn't 
   have to represent a real device.
   - After a successful two factor authentication the device is stored in 
   the session. The middleware *TFAMiddleware *(which must be installed 
   after *AuthenticationMiddleware*) sets this device for the user coming 
   from the request object.
   - *is_two_factor_authenticated* of *AbstractBaseUser *evaluates to True 
   only if a device is set.



   - The authentication process is handled by two views. *FirstFactorLoginView 
   *is responsible for authenticating with the first factor and redirecting 
   to *SecondFactorLoginView *on success. *SecondFactorLoginView *handles 
   the authentication with the second factor and redirects to a defined URL on 
   success. If the user accessing the *SecondFactorLoginView* isn't 
   authenticated with the first factor he is redirected to the 
   *FirstFactorLoginView*.
   - The *SecondFactorLoginView *can have multiple forms. 
   - This is done because different 2FA methods can require different input 
  fields (e.g different input types, labels, number of input fields). 
  - Also this allows to display multiple forms, for example when it is 
  desired to show the form for the default 2FA method and the backup method 
  on one page.
  - By default *SecondFactorLoginView *loads all the forms specified in 
  the setting *TFA_FORMS*. Which forms are displayed can be adjusted in 
  the template or by overriding *get_form_classes()*. Only one form 
  gets validated on a POST request. Therefore when submitting the form the 
  2FA method name needs to be included as a HTTP POST parameter.
  - For example if the setting *TFA_FORMS* is the following:
   
TFA_FORMS = [
{'METHOD_NAME': 'TOTP', 'FORM_PATH': 
'django.contrib.twofactorauth.forms.TOTPAuthenticationForm'},
{'METHOD_NAME': 'Backup Token', 'FORM_PATH': 
'django.contrib.twofactorauth.forms.BackupTokenAuthenticationForm'},
]
   
  and the *TOTPAuthenticationForm *is submitted, then 
type=TOTP must be included, for example in a button tag:


  {% csrf_token %}
  {{ forms.TOTP.as_p }}
  {% trans 
'Submit' %}
   


   - For convenience there is the *tfa_required* decorator and the mixin 
   *TFARequiredMixin*. They work analogous to the *login_required* 
   decorator and *LoginRequiredMixin *from django.contrib.auth. Instead of 
   checking for *is_authenticated* they check for 
   *is_two_factor_authenticated*. If the user is not two factor 
   authenticated he is redirected to a specified URL.
   - For example the URL can be specified by setting *TFA_LOGIN_URL* to 
   "tfa:first_factor_login" and would point to the *FirstFactorLoginView*. 
   By default the *FirstFactorLoginView *requires the user to authenticate 
   with the first factor and redirects on success to *SecondFactorLoginView*. 
   If desired the *FirstFactorLoginView *can redirct an already one factor 
   authenticated user to *SecondFactorLoginView *right away, for this 
   *redirect_authenticated_user* needs to be set to True. After 
   successfully authenticating with the second factor the user is redirected 
   to the initially inaccessible page. For this last redirect to work the 
   redirect URL is transfered from *FirstFactorLoginView *to 
*SecondFactorLoginView 
   *by appending it as a HTTP GET parameter.



   - For the admin site to support 2FA the class *AdminSiteTFARequired *was 
   created which i

Re: DEP201 / Simplified URL routing progress report

[Adam Johnson]

For those who don't know, the PR is here: https://github.com/
django/django/pull/7482


> However, in doing so I "had" to get rid of a minor performance
> optimisation: the caching of `.regex` using LocaleRegexDescriptor, so there
> might be a performance drawback in case one does not use the
> lazy/translateable URLs. I'm not sure if this performance drawback is going
> to be significant enough to actually be bothered by it.
>

That's probably a big one, I think most apps don't use translated URL's.
Also at DUTH last year Carl Meyer talked about how Instagram has custom
code to cache their translated URL's *as well* so it's clearly worth it for
some applications :) But I'm sure we can work out a way to keep caching.

Another issue that I now have is that if one does not use the `reverse`
> functionality, the needed parts are now prepared (whereas before, loading
> this was delayed until the first call to `reverse`).
>

 I don't think this is such a worry, I haven't seen a Django app that
doesn't use reverse(), and I guess the memory usage isn't going to be too
high.

Anyway, looking good, keep up the good work!

On 12 June 2017 at 05:32, Sjoerd Job Postmus  wrote:

> Hi all,
>
> I finally had some more time to continue on the WIP implementation of
> DEP201, and spent it on getting two missing items working:
>
> * Showing the supplied argument to `path` in the technical 404 page.
> * Making `path` work with "lazy" (think `ugettext_lazy`) arguments.
>
> I also (finally) reserved a dedicated test-folder `urlpatterns` for some
> (as of now 1) tests.
>
> However, in doing so I "had" to get rid of a minor performance
> optimisation: the caching of `.regex` using LocaleRegexDescriptor, so there
> might be a performance drawback in case one does not use the
> lazy/translateable URLs. I'm not sure if this performance drawback is going
> to be significant enough to actually be bothered by it.
>
> Another issue that I now have is that if one does not use the `reverse`
> functionality, the needed parts are now prepared (whereas before, loading
> this was delayed until the first call to `reverse`).
>
> If possible, I would really appreciate it if somebody could do a brief
> review of the code to check if it's not getting "too bad".
>
> During the upcoming week I hope to complete the set of test-cases and have
> the code functioning. How should I proceed from there?
>
> Kind regards,
> Sjoerd Job Postmus
>
> --
> 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/ms
> gid/django-developers/220dbc21-fcae-41f7-9ce5-f57176ad8420%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM1-wSWSm6Q%2BH%3D-zV1y7uCSU_oZOrq19f9G3wuFDavRNeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Makemigrations hooks for third-party apps?

[Josh Smeaton]

Can you provide the operations that users can then import into their 
migrations, similarly to how contrib.postgres provides the HStoreExtension 
operation [0]? The import could even be a function taking the extended 
model that returns the appropriate operation. This might be a bit more 
lo-fi than hooking the pre-migrate signal, and require users to do the 
right thing, but it sounds better than copy/pasting templates.

[0] 
https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/operations/#creating-extension-using-migrations

On Wednesday, 7 June 2017 06:45:05 UTC+10, Craig de Stigter wrote:
>
> Hi there
>
> I'm in the early stages of developing a third party app which makes heavy 
> use of postgres extensions. The app provides an abstract model, so I won't 
> have direct control of user's models or migrations. I'm having trouble 
> getting it to generate sensible migrations for users.
>
> At present the migration process for users is going to be "copy and paste 
> my migration file template into your project, and change the model names to 
> match your app". As far as I can tell there is no way to generate 
> migrations with anything custom.
>
> The operations I need to generate are:
>
>- CreateExtension()
>- RunSQL() - (to create slightly non-standard constraints)
>
> e.g. perhaps my model could supply a couple of methods:
>
>- Model.Meta.pre_creation_operations() - returns a list of operations 
>to apply before the auto-detected model operations, e.g. creating 
>extensions etc
>- Model.Meta.post_creation_operations() - the same but applied after 
>the auto-detected operations, e.g. adding constraints/indexes.
>
> I'm envisaging that the operations returned from both methods would be 
> deconstructed and copied into migration files when makemigrations is run.
>
> Has there been any discussion about this previously? I haven't found any.
>
> Thanks
> Craig de Stigter
>

-- 
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/138eeec1-5719-4295-8161-85b04ea2e6e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: On ASGI...

[Andrew Godwin]

On Mon, Jun 12, 2017 at 10:53 PM, Tom Christie 
wrote:

> > def handler(channel_layer, channel_name, message):
>
> Oh great! That's not a million miles away from what I'm working towards on
> my side.
> Are you planning to eventually introduce something like that as part of
> the ASGI spec?
>

I had been pondering doing so for a while and I think this thread has
catalysed me to actually do it (and incorporate support for it into the
Channels/asgiref stuff too, so everything can use a common Worker class if
it's running in a separate process)


>
> > So is the channels object just a place to stuff different function
> handlers?
>
> No, it's just a different interface style onto exactly the same set of
> channel send/receive functionality.
> It's the difference between this:
>
> def hello_world(channel_layer, channel_name, message):
> ...
> channel_layer.send(message['reply_channel'], response)
>
> And this:
>
> def hello_world(message, channels):
> ...
> channels['reply'].send(response)
>

This is the sort of thing I would not put in a spec, but leave the
framework to do if it likes (the same way Django adds things like
message.reply_channel to the original message)


>
> > Why not just pass the channel layer there and use the API on that
> directly? e.g.: channel_layer.group_send("chat", message["text"])
>
> With the groups example I wanted to demonstrate that we don't need extra
> "extensions" API introduced onto the channel layer in order to support a
> broadcast interface.
>

Well the extensions are there for a reason :) But again, I think my goal in
ASGI is to provide a solid but not necessarily pretty base, and let things
build on top of it as they wish.


>
> > then frameworks can do per-channel-name dispatch if they like
>
> Yup, the channel name is certainly necessary.
> A possible alternative is including that in the message itself, which I
> also quite like as an option because you more naturally end up with a nice
> symmetry of having the signature of the child routes match the signature of
> the parent.
>
>def app(message, channels):
> channel = message['channel']
> if channel == 'http.request':
>http_request(message, channels)
> elif channel == 'websocket.connect':
>websocket_connect(message, channels)
> elif ...
>
> That's what I'm rolling with for the moment, but it's not something I'm
> necessarily wedded to.
>

I actually pondered this during the spec development (also considered
having a separate channel names dict inside, with the current name and
multiple reply names, e.g. "send" and "close"). Right now, I like the base
level interface as it is, because the ideological separation makes me
happier - you get out exactly what you put in, and there's no special
keyword to reserve - but the truth is that several of the backends actually
do this to support the process-local channels efficiently, so maybe it is
worth revisiting.


>
> I've done a bunch more work towards all this, so it'd worth checking out
> https://github.com/tomchristie/uvicorn in it's current state. That should
> make the interface style I'm considering more clear. (Focusing on asyncio
> there, but could equally present an equivalent-but-syncronous interface.)
>
>
I note that your examples do not include "receiving messages from a
WebSocket and sending replies" - I would love to see how you propose to
tackle this given your current API, and I think it's the missing piece of
what I understand.


> There are also now initial implementations for both WSGI-to-ASGI and
> ASGI-to-WSGI adapters.
>
>
There's a mostly-complete one in asgiref over here for WSGI-to-ASGI:
https://github.com/django/asgiref/blob/master/asgiref/wsgi.py

If you are feeling like it, I would love to have just one pair of canonical
adapters in the asgiref repo that everyone can use. The ASGI-to-WSGI
adapter can probably be written based on the callable pattern I described
at the top.

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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uo2%2Bm63WKKN7MLYkbGj%3Duro%3D9-XcGcWmC-5DrQ4FO%2BGww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider making asgi_rabbitmq an official Django project.

[Andrew Godwin]

Hi Artem,

Thanks for adding the comments - it does look better. The thing I would
like to have is more feedback from Django core about this; I've not heard
anyone's opinion but mine, and I am not entirely sure if we should do this
(I am also not entirely sure asgi_ipc should be a Django project some days).

Andrew

On Mon, Jun 12, 2017 at 6:19 AM, Artem Malyshev 
wrote:

> Hi Andrew,
>
> I'm very glad to hear it's considered useful. If you look at recent master
> you can see that I've added documentation and comments to the code.
>
> Exact commit https://github.com/proofit404/asgi_rabbitmq/commit/
> 9add0b8fec10ff93f8a813838f4f8ad87fde7e1f
>
> Also, I found the second maintainer for the project, Andrii Soldatenko.
> He is in the mail carbon copy.
>
> Any insights what to do next?
>
> Regards, Artem.
>
> On Sunday, June 11, 2017 at 4:08:20 AM UTC+3, Andrew Godwin wrote:
>>
>> Hi Artem,
>>
>> I know we've discussed this privately but I want to put some things on
>> the public list (and get at least one reply).
>>
>> My view is that it would be useful to have it maintained, but I do not
>> personally have the spare time to help maintain it, so it would need at
>> least one other person to help you maintain it before we could accept it
>> (they would not have to be existing core, but would need some history of
>> open-source maintenance)
>>
>> The other thing would be to see the existing code have more comments and
>> documentation; currently it has very few comments, in particular.
>>
>> Andrew
>>
>> On Thu, Jun 8, 2017 at 9:39 PM, Artem Malyshev 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> asgi_rabbitmq is Channels layer on top of RabbitMQ.  It was originally
>>> developed as part of Mozilla funding program.
>>>
>>> I've complete few major milestones after this.  Now it's used in few
>>> production systems.  It implements the ASGI specification exactly and
>>> performs well.
>>>
>>> I want to make asgi_rabbitmq an official Django project.
>>>
>>> Reasons why I want this happens:
>>>
>>> - It will be widely used.  Major changes in the Channels and ASGI will
>>> take this library into account.
>>>
>>> We need:
>>>
>>> - Discuss if it's interesting at all for Django project.  Find at least
>>> one more person who understands library code.  Documentation has a
>>> comprehensive chapter about internal design and implementation.
>>>
>>> Conditions under which I prefer it happens:
>>>
>>> - I want to keep commit access for this repository for future
>>> development and fixes.  - I'll keep it up to date with coming channels
>>> releases.  - I'll do initial preparation steps for code transfer like code
>>> clean up if necessary.  But I need receive some comments after code review.
>>>
>>> Project repository: https://github.com/proofit404/asgi_rabbitmq
>>>
>>> Regards, Artem.
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/ms
>>> gid/django-developers/69328d61-68fd-47b8-8f1b-a4f0cc85f7cf%
>>> 40googlegroups.com
>>> 
>>> .
>>> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/d232cdec-ff7b-4e0c-a2bd-
> d5d086ca7f68%40googlegroups.com
> 
> .
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upgLasQDY%3DN-eNeXpQp%3DAFgA9zo-P-iGZptfnY6UjEVHQ%40mail