Re: SMTP configuration in a dict

[Andi Albrecht]

Hi,

On Wed, May 28, 2014 at 1:06 PM, Julian Wachholz  wrote:
> Hi django-developers
>
> I'd like to propose a relatively small change to the way we configure our
> SMTP email backends.
> Up until now, configuring your SMTP backend took up to 6 individual
> settings, ranging from EMAIL_HOST to EMAIL_USE_SSL etc.
>
> We already have a dictionary to configure things like caches and databases,
> so why not for sending email (at least with the SMTP backend).
> I've already created a POC branch complete with docs and deprecation
> warnings here:
> https://github.com/julianwachholz/django/tree/feature/12factor-smtp
>
> Please let me know what you think!

I've came across this too while working on
https://code.djangoproject.com/ticket/20743 (add support for ssl
keyfile/certfile). If support for keyfile/certfile would be added two
additional settings for the SMTP backend would be required to
configure the file paths.

The current settings for emails is confusing IMO since some settings
are for emails in general (EMAIL_BACKEND, EMAIL_SUBJECT_PREFIX) and
others are backend related (EMAIL_FILE_PATH for the file backend,
several others for the SMTP backend).

IMO it's a good idea to make it clear which settings belong to which
backend and a dictionary-based solution sounds good to me.

--
Andi

>
> Cheers
> Julian
>
> PS: This change is only so altruistic, as it would enable me to include
> email settings in my dj-database-url fork
> (https://github.com/julianwachholz/dj-config-url).
>
> --
> 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/3ed1fa0e-8676-412e-8265-aaa196465ffb%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" 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/CAFKCSkSOCcWkU3QKk0g3E2bRx1J52e9OaU7ShMBR9jZ%2B1FmRXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

#10355 Add support for email backends

[Andi Albrecht]

Hi,

I'm interested in working on #10355 "Add support for email backends."

IMHO it's an good idea to make the email backend configurable. There
are at least two use cases I can think of. The first is to send email
with other services than SMTP, like App Engine as noted in the
ticket's description. The second is to deliver email asynchronously,
like the django-mailer application does already.

The ticket currently needs a design decision, so my question is what
the actual concerns to change this are.

I would propose the following changes. It's a very simplistic approach
that tries to keep the current API as much as possible:

Add a new setting EMAIL_BACKEND. A string that can be resolved to a
class. Default should be the current SMTP implementation.

Provide a base class for mail backends. A mail backend must provide
the method send_messages(email_messages) and must return the number of
messages sent to provide backward compatibility. The constructor of a
mail backend should take at least the keyword argument fail_silently
(default: False). What I'm a bit unsure about are additional
constructor arguments. Currently the SMTP backend allows in addition
host, port, username, password and use_tls. Those are very
SMTP-specific, but only username and password are used by the
mail.send_mail* APIs. It would be an agreement to allow username and
password in addition to fail_silently to not break the send_mail* API.
The SMTP backend could accept host, port and use_tls as extra keywords
again to provide backward compatibility for code that directly uses
SMTPConnection (within Django SMTPConnection is not used outside
django.core.mail). I would suggest to rename SMTPConnection to
SMTPBackend, but only if this would break too much third-party code as
SMTPConnection is mentioned in the docs.

The test utils could be refactored to use a TestMailBackend instead of
monkey-patching the mail module, but this would be a fairly invisible
change as it would just change the way how the test utils provide the
mailbox attribute in the mail module for unittests.

A nice addition to Django would be to include parts of django-mailer
to provide a backend for asynchronous mail delivery. That could be the
models and command line script to deliver mails. While thinking about
this, django-mailer has a nice option for setting priorities to mails.
IMO Django's API for sending mails should be as simple as possible
(like it is today), but a priority option would be a nice addition
even if the SMTP backend (as the default) wouldn't respect this option
when sending mails.

Adding a App Engine backend is not covered here. I think it's up to
third-party code to add support for sending mails on App Engine.
However, such a backend would be pretty easy to implement.

It would be nice to get some feedback on this suggestions and in a
first step to find a design decision about #10355. Even if the
decision is to not change anything for good reasons :)


Regards,

Andi

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: #10355 Add support for email backends

[Andi Albrecht]

On Fri, Aug 21, 2009 at 12:39 PM, Tim
Chase wrote:
>
>> In terms of the SMTP-specific settings (host, port, username, password
>> and use_tls), I personally feel that those parameters should be in the
>> settings module and not in the code. Although at the moment,
>> django.core.mail will use certain settings if said parameters are left
>> out.
>
> Having email settings defined globally precludes the ability to
> do things like create a web email application for which each user
> has their own email (usually SMTP/IMAP/POP) settings.  While yes,
> I could see having some defaults at the settings.py level, it
> should be possible to override those at the call level.

A web-based email client needs probably a much more fine-grained
access to the SMTP protocol to handle errors more accurate than an API
that just sends out mails and simply fails (optional silently) when
any error occurs. If you want to include this in Django's mail API, I
suppose you end up with a smtplib clone :)
POP and IMAP are totally different topics.

>
> -tim
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: #10355 Add support for email backends

[Andi Albrecht]

On Fri, Aug 21, 2009 at 11:53 AM, Zachary
Voase wrote:
>
> Hi Andi,
>
> On 21 Aug 2009, at 05:34, Andi Albrecht wrote:
>
>> Hi,
>>
>> I'm interested in working on #10355 "Add support for email backends."
>>
>> IMHO it's an good idea to make the email backend configurable. There
>> are at least two use cases I can think of. The first is to send email
>> with other services than SMTP, like App Engine as noted in the
>> ticket's description. The second is to deliver email asynchronously,
>> like the django-mailer application does already.
>
> I wholeheartedly agree.
>
>> The ticket currently needs a design decision, so my question is what
>> the actual concerns to change this are.
>>
>> I would propose the following changes. It's a very simplistic approach
>> that tries to keep the current API as much as possible:
>>
>> Add a new setting EMAIL_BACKEND. A string that can be resolved to a
>> class. Default should be the current SMTP implementation.
>>
>> Provide a base class for mail backends. A mail backend must provide
>> the method send_messages(email_messages) and must return the number of
>> messages sent to provide backward compatibility. The constructor of a
>> mail backend should take at least the keyword argument fail_silently
>> (default: False). What I'm a bit unsure about are additional
>> constructor arguments. Currently the SMTP backend allows in addition
>> host, port, username, password and use_tls. Those are very
>> SMTP-specific, but only username and password are used by the
>> mail.send_mail* APIs. It would be an agreement to allow username and
>> password in addition to fail_silently to not break the send_mail* API.
>> The SMTP backend could accept host, port and use_tls as extra keywords
>> again to provide backward compatibility for code that directly uses
>> SMTPConnection (within Django SMTPConnection is not used outside
>> django.core.mail). I would suggest to rename SMTPConnection to
>> SMTPBackend, but only if this would break too much third-party code as
>> SMTPConnection is mentioned in the docs.
>
> This I disagree with slightly. My main concern is the single-backend
> architecture; many websites will probably want to use more than one
> method for sending e-mail. In addition, if mail backends only need to
> implement one method, why not just have EMAIL_BACKEND refer to a
> callable instead?
>
> In terms of the SMTP-specific settings (host, port, username, password
> and use_tls), I personally feel that those parameters should be in the
> settings module and not in the code. Although at the moment,
> django.core.mail will use certain settings if said parameters are left
> out.
>
> I think a slightly better architecture would be this:
>
> * Make full use of the existing Django signals framework to send e-
> mail. Have callables which implement 'send_messages()' connect to a
> 'sendmail' signal through the use of a simple decorator or connector.
> These callables will connect with the 'sender' keyword argument, which
> will be a string which uniquely identifies that backend; so AppEngine
> might be 'app_engine', SMTP 'smtp', and so on.

I have some concerns with this. Letting a backend connect to a sender
that determines the backend to use implies that someone who wants to
use the mail API already needs to know which backends are available
and has to decide which backend he wants to use. I think it's up to
the administrator to choose which backend should be used for sending
mails. The send_mail functions should be agnostic of this setting.

OTOH signals could be a nice addition and could be used for example to
log failed messages or to modify messages before sending. But I
wouldn't use them to actually send the message.

>
> * To send a message, just send on the 'sendmail' signal, with a
> 'sender' equal to whatever backend you want to use for that particular
> message or batch of messages. Failing silently can be done with the
> signals framework, using 'send_robust()' to catch errors and then
> deciding whether or not to raise them later. Of course, nice wrappers
> would be provided over all of this, so that the code which sends mail
> does not need to know the signals API.
>
> * E-mail backends can, by default, configure themselves from the
> project settings. Using signals means that it’s also quite easy to
> dynamically create a backend, connect it to the dispatcher, send some
> signals, and then disconnect it.
>
> What do you think about this? I might work on a simple proof-of-
> concept reusable application.
>
> Regards,
> Zack
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: #10355 Add support for email backends

[Andi Albrecht]

On Fri, Aug 21, 2009 at 7:23 AM, Russell
Keith-Magee wrote:
>
> On Fri, Aug 21, 2009 at 12:34 PM, Andi
> Albrecht wrote:
>>
>> Hi,
>>
>> I'm interested in working on #10355 "Add support for email backends."
>>
>> IMHO it's an good idea to make the email backend configurable. There
>> are at least two use cases I can think of. The first is to send email
>> with other services than SMTP, like App Engine as noted in the
>> ticket's description. The second is to deliver email asynchronously,
>> like the django-mailer application does already.
>>
>> The ticket currently needs a design decision, so my question is what
>> the actual concerns to change this are.
>
> I think the original concern was the time required to triage the
> ticket :-) The original report is fairly light on detail, so I suspect
> Jacob punted the proposal to DDN in a fit of rapid triage.
>
> However, your proposal gives us a bit more detail to work with. On the
> whole, I have to say I like what I see. This is the sort of thing I'd
> like to see more of in Django - less specific feature enhancements
> baked into the core, and more opening of interfaces that let people
> plug their own capabilities in where they need to.
>
>> I would propose the following changes. It's a very simplistic approach
>> that tries to keep the current API as much as possible:
>
> To qualify this - "as much as possible" must include "100% backwards
> compatible with 0 code changes with all public advertised interfaces".

OK, that's clear :) I fully agree.

>
>> Add a new setting EMAIL_BACKEND. A string that can be resolved to a
>> class. Default should be the current SMTP implementation.
>
> No problem with this, and follows the precedent set by other backends
> (such as the cache backend)
>
>> Provide a base class for mail backends. A mail backend must provide
>> the method send_messages(email_messages) and must return the number of
>> messages sent to provide backward compatibility. The constructor of a
>> mail backend should take at least the keyword argument fail_silently
>> (default: False). What I'm a bit unsure about are additional
>> constructor arguments. Currently the SMTP backend allows in addition
>> host, port, username, password and use_tls. Those are very
>> SMTP-specific, but only username and password are used by the
>> mail.send_mail* APIs. It would be an agreement to allow username and
>> password in addition to fail_silently to not break the send_mail* API.
>
> I'll need to look into this in more detail. I'm hesitant to lock down
> APIs like this too much - the more rigid you make an interface, the
> harder it becomes to use it in interesting way. I'm sure that some
> insights will emerge as a result of writing the code.
>
>> The SMTP backend could accept host, port and use_tls as extra keywords
>> again to provide backward compatibility for code that directly uses
>> SMTPConnection (within Django SMTPConnection is not used outside
>> django.core.mail). I would suggest to rename SMTPConnection to
>> SMTPBackend, but only if this would break too much third-party code as
>> SMTPConnection is mentioned in the docs.
>
> Breaking _any_ third party code is a non-starter. We can deprecate the
> old name and provide an alias from the old name to the new name, but
> historical usage must continue without modification.
>
>> The test utils could be refactored to use a TestMailBackend instead of
>> monkey-patching the mail module, but this would be a fairly invisible
>> change as it would just change the way how the test utils provide the
>> mailbox attribute in the mail module for unittests.
>
> This is an interesting suggestion all by itself. It also dovetails
> nicely with #8638. That ticket was on the list for v1.1, and
> originally proposed including a 'test email server'. Ultimately, it
> was decided not to include an email server, but to document the ways
> you could use existing mail servers.
>
> A 'test email backend' (as well as a dummy no-mail-at-all backend, and
> a log-to-console/log-to-file backend) is a different way to target the
> underlying problem posed by #8638.

A dummy backend/log backend sounds good. I'll add them. Is it time to
make the mail module a package? Preserving the current namespace, of
course...

>
>> A nice addition to Django would be to include parts of django-mailer
>> to provide a backend for asynchronous mail delivery. That could be the
>> models and command line script to deliver mails. While thinking about
>> this, django-mailer has a nice 

Re: #10355 Add support for email backends

[Andi Albrecht]

On Fri, Aug 21, 2009 at 1:45 PM, Russell
Keith-Magee wrote:
>
> On Fri, Aug 21, 2009 at 5:53 PM, Zachary
> Voase wrote:
>>
>> Hi Andi,
>>
>> On 21 Aug 2009, at 05:34, Andi Albrecht wrote:
>>
>>> Hi,
>>>
>>> I'm interested in working on #10355 "Add support for email backends."
>>>
>>> IMHO it's an good idea to make the email backend configurable. There
>>> are at least two use cases I can think of. The first is to send email
>>> with other services than SMTP, like App Engine as noted in the
>>> ticket's description. The second is to deliver email asynchronously,
>>> like the django-mailer application does already.
>>
>> I wholeheartedly agree.
>>
>>> The ticket currently needs a design decision, so my question is what
>>> the actual concerns to change this are.
>>>
>>> I would propose the following changes. It's a very simplistic approach
>>> that tries to keep the current API as much as possible:
>>>
>>> Add a new setting EMAIL_BACKEND. A string that can be resolved to a
>>> class. Default should be the current SMTP implementation.
>>>
>>> Provide a base class for mail backends. A mail backend must provide
>>> the method send_messages(email_messages) and must return the number of
>>> messages sent to provide backward compatibility. The constructor of a
>>> mail backend should take at least the keyword argument fail_silently
>>> (default: False). What I'm a bit unsure about are additional
>>> constructor arguments. Currently the SMTP backend allows in addition
>>> host, port, username, password and use_tls. Those are very
>>> SMTP-specific, but only username and password are used by the
>>> mail.send_mail* APIs. It would be an agreement to allow username and
>>> password in addition to fail_silently to not break the send_mail* API.
>>> The SMTP backend could accept host, port and use_tls as extra keywords
>>> again to provide backward compatibility for code that directly uses
>>> SMTPConnection (within Django SMTPConnection is not used outside
>>> django.core.mail). I would suggest to rename SMTPConnection to
>>> SMTPBackend, but only if this would break too much third-party code as
>>> SMTPConnection is mentioned in the docs.
>>
>> This I disagree with slightly. My main concern is the single-backend
>> architecture; many websites will probably want to use more than one
>> method for sending e-mail.
>
> I'm not sure I agree with your assertion of "many"."Some" might be
> accurate. "Your" is probably more accurate :-)
>
> I've got many websites in the field, and not one of them has needed
> anything more than trivial email handling. We've managed to get to
> v1.1 and AppEngine support is the first time that pluggable email
> backends have really been raised as an issue.
>
> This is hardly surprising. After all, email is email. You have an SMTP
> server, you connect to it, you send your mail. AppEngine is a weird
> case in that they provide an email-sending API rather than using SMTP,
> but that's an artefact of the platform. Once you have one email
> sending capability, I find it hard to believe that most people will
> need a second.
>
> I don't doubt that there are applications that will require more than
> one mail server, but I'm comfortable calling them edge cases. If you
> have highly specialized mail requirements, then it makes sense that
> you should have a highly specialized mail server handling.
>
> That said, there isn't really that much difference between the simple
> and complex case - it's just a matter of defaults.
>
> Django needs to have a default Email backend, guaranteed available.
>
> EmailMessage.send() uses the 'default' backend - essentially just
> calling backend.send_messages([msg])
>
> backend.send_messages() also exists as a direct call.
> SMTPConnection().send_messages() is really just a shortcut for
> instantiating and using an SMTP connection with the default settings.
>
> You're not compelled to use the default connection though. You could
> instantiate multiple instances of different backends, and use them to
> call other_backend.send_messages().
>
> I see this working almost exactly as the Cache backend works right
> now. There is a base interface for caching. There are several cache
> backends; dummy and locmem are handy for testing, but if you're
> serious, the only one that gets used is memcached. There is a default
> cache instantiated as a res

Re: #10355 Add support for email backends

[Andi Albrecht]

I've attached a patch to the issue on the tracker. The patch splits up
the mail module into a package and provides the backend functionality.
Documented functions and classes are of course available in the
top-level module. Undocumented methods like make_msgid() are not
available in django.core.mail anymore, but an additional import could
be added easily.

Two demo backends are attached too. One implements a backend for
sending mails through App Engine's mail API, the other implements a
backend for django-mailer. In case someone is interested, I've made
the full examples of both backends available on bitbucket:
http://bitbucket.org/andialbrecht/django_mailbackend_examples/

Andi

On Sat, Aug 22, 2009 at 9:15 AM, Russell
Keith-Magee wrote:
>
> On Sat, Aug 22, 2009 at 1:34 PM, Andi
> Albrecht wrote:
>>
>> On Fri, Aug 21, 2009 at 1:45 PM, Russell
>> Keith-Magee wrote:
>>>
>>> On Fri, Aug 21, 2009 at 5:53 PM, Zachary
>>> Voase wrote:
>>>>
>>>> Hi Andi,
>>>>
>>>> On 21 Aug 2009, at 05:34, Andi Albrecht wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm interested in working on #10355 "Add support for email backends."
>>>>>
>>>>> IMHO it's an good idea to make the email backend configurable. There
>>>>> are at least two use cases I can think of. The first is to send email
>>>>> with other services than SMTP, like App Engine as noted in the
>>>>> ticket's description. The second is to deliver email asynchronously,
>>>>> like the django-mailer application does already.
>>>>
>>>> I wholeheartedly agree.
>>>>
>>>>> The ticket currently needs a design decision, so my question is what
>>>>> the actual concerns to change this are.
>>>>>
>>>>> I would propose the following changes. It's a very simplistic approach
>>>>> that tries to keep the current API as much as possible:
>>>>>
>>>>> Add a new setting EMAIL_BACKEND. A string that can be resolved to a
>>>>> class. Default should be the current SMTP implementation.
>>>>>
>>>>> Provide a base class for mail backends. A mail backend must provide
>>>>> the method send_messages(email_messages) and must return the number of
>>>>> messages sent to provide backward compatibility. The constructor of a
>>>>> mail backend should take at least the keyword argument fail_silently
>>>>> (default: False). What I'm a bit unsure about are additional
>>>>> constructor arguments. Currently the SMTP backend allows in addition
>>>>> host, port, username, password and use_tls. Those are very
>>>>> SMTP-specific, but only username and password are used by the
>>>>> mail.send_mail* APIs. It would be an agreement to allow username and
>>>>> password in addition to fail_silently to not break the send_mail* API.
>>>>> The SMTP backend could accept host, port and use_tls as extra keywords
>>>>> again to provide backward compatibility for code that directly uses
>>>>> SMTPConnection (within Django SMTPConnection is not used outside
>>>>> django.core.mail). I would suggest to rename SMTPConnection to
>>>>> SMTPBackend, but only if this would break too much third-party code as
>>>>> SMTPConnection is mentioned in the docs.
>>>>
>>>> This I disagree with slightly. My main concern is the single-backend
>>>> architecture; many websites will probably want to use more than one
>>>> method for sending e-mail.
>>>
>>> I'm not sure I agree with your assertion of "many"."Some" might be
>>> accurate. "Your" is probably more accurate :-)
>>>
>>> I've got many websites in the field, and not one of them has needed
>>> anything more than trivial email handling. We've managed to get to
>>> v1.1 and AppEngine support is the first time that pluggable email
>>> backends have really been raised as an issue.
>>>
>>> This is hardly surprising. After all, email is email. You have an SMTP
>>> server, you connect to it, you send your mail. AppEngine is a weird
>>> case in that they provide an email-sending API rather than using SMTP,
>>> but that's an artefact of the platform. Once you have one email
>>> sending capability, I find it hard to believe that most people will
>>> need a second.
>>>
>>

Re: App Engine support

[Andi Albrecht]

On Sun, Aug 30, 2009 at 2:52 PM, Waldemar Kornewald wrote:
>
> On Aug 28, 1:49 am, Russell Keith-Magee 
> wrote:
>> To the extent that I'm in a position to provide design guidance and
>> feedback from the perspective of the Django Core, put me on this list
>> too. Time permitting, I might be able to contribute some code, too.
>
> Awesome. Could you please provide some feedback on Andi's latest patch
> (or commit it if it's good enough)?
> http://code.djangoproject.com/ticket/10355

No need to hurry. I'll keep this in sync with the trunk - should be
really unproblematic :)

Regarding the App Engine backend: I have some minimal code here for
the database backend. Currently it does nothing useful but it provides
at least the backed so that it is importable in the shell.
Andy, are you working on this too? Maybe you've got more on your desk
than just a database backend stub...

BTW, what would be a good name for this backend? "appengine", or is
"bigtable" more appropriate?

Andi

>
> Thanks a lot!
>
> Bye,
> Waldemar
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: backend query_class() question

[Andi Albrecht]

AFAIKT query_class() is only used to set the Query attribute in
django.db.models.sql.query. The relevant code part in sql.query is

# Use the backend's custom Query class if it defines one. Otherwise, use the
# default.
if connection.features.uses_custom_query_class:
Query = connection.ops.query_class(BaseQuery)
else:
Query = BaseQuery

So it's not much an issue with query_class() itself but with BaseQuery
in this module. I'd predict that it depends on the refactoring how
much this affects backends for non-relational databases at all.

Andi

On Wed, Sep 2, 2009 at 8:44 AM, Waldemar Kornewald wrote:
>
> Hi,
> why does the backend's query_class() function get the default query
> class as its parameter? Can't the backend just import BaseQuery? I'm
> asking because with different BaseQuery implementations (for SQL and
> non-SQL) there is no real default query class, anymore.
>
> Bye,
> Waldemar Kornewald
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: non-relational DB

[Andi Albrecht]

On Thu, Oct 22, 2009 at 2:07 PM, Russell Keith-Magee
 wrote:
>
> On Thu, Oct 22, 2009 at 7:46 PM, Waldemar Kornewald
>  wrote:
>>
>> Hi again,
>> now a little question:
>>
>> Some fields do type conversions. For example, TimeField converts
>> datetime objects into time objects.
>> App Engine doesn't support time, but only datetime, so should we do
>> such conversions at the backend level or should we expect the field to
>> handle it (esp. if it already has such conversion code)?
>
> I'm unsure what problem you're having here. The backend needs to
> return a type that the TimeField can turn into a Python Time object.
> TimeField is fairly liberal in what it will accept - DateTime objects,
> Time objects, and strings that express a time will all be handled.
>
> As long as your backend returns one of these acceptable types, you're done.
>
>> What's the status of the email backends ticket? There hasn't been any
>> reply to Andi Albrecht's latest patch and comment.
>> http://code.djangoproject.com/ticket/10355
>> This is essential for supporting all kinds of cloud platforms.
>
> We're in the process of doing feature voting for v1.2. Personally, I'm
> happy with the state of the patch, but there have been a couple of -1
> votes for the patch, which means that some people still need to be
> convinced that it's the right thing to do. Once voting is finished, we
> may need to revisit this issue on django-dev.

To give a short feedback. I'm still there and I've read most of the
comments given in the voting sheet. I'd happy to address the concerns
once voting is finished - in a different thread, of course :)

>
> Yours,
> Russ Magee %-)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Advocacy for Email-01 (email backends)

[Andi Albrecht]

On Fri, Oct 30, 2009 at 4:03 PM, Alex Gaynor  wrote:
>
> On Fri, Oct 30, 2009 at 10:58 AM, Luke Plant  wrote:
>>
>> On Sunday 25 October 2009 07:22:27 Russell Keith-Magee wrote:
>>
>>> I'm keen to see a resolution to this problem. To that end, I'm
>>> interested in hearing specific criticisms or concerns with the
>>>  current backend proposal. I'm also interested in any alternate
>>>  approaches to this problem.
>>
>> I'm completely fine on this proposal.  Apparently I voted '-0', I'm
>> not sure precisely why as I didn't leave any specific comment, but I
>> would change that to +0 now (I have no specific need for it myself,
>> but can see that it's an important improvement for lots of people, and
>> it can be implemented cleanly).
>>
>> I presume that the only built-in email backends would be the existing
>> SMTP one, one for testing (which is just a code shuffle really), and a
>> 'write to standard out' one for debugging (which is trivial and
>> completely un-critical anyway), so this doesn't really add any
>> maintenance burden to Django.

Currently there are two more backend implementation in the proposal: A
dummy backend that does nothing and a backend that writes to message
to the file system.

>>
>> Regards,
>>
>> Luke
>>
>> --
>> A common mistake that people make when trying to design something
>> completely foolproof is to underestimate the ingenuity of complete
>> fools.  -- Douglas Adams
>>
>> Luke Plant || http://lukeplant.me.uk/
>>
>> >
>>
>
> Amusingly it appears that since Jannis got his wings^H^H^H^H^H^H
> commit bit his -1 became a veto :)

Would be nice to hear from Janis how django-mailer could be extended
to support different backends then. :)

>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Last chance to object to new features

[Andi Albrecht]

On Mon, Nov 2, 2009 at 4:53 PM, Jacob Kaplan-Moss  wrote:
>
> On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee
>  wrote:
>> A quick reminder - if you have any objections or feedback on #10109,
>> the M2M refactor [1], I intend to land this patch in approximately 48
>> hours.
>
> I've left a few comments in that thread, but they don't need to be
> addressed pre-merge. Fire away!
>
>> Also, following some mailing list and IRC discussion [2], I'll be
>> trying to land #10355 at the same time. This is the addition of the
>> email backend API.
>
> I've left a few notes on the ticket. The only one that needs to be
> addressed pre-merge is a simple design decision, and the final call's
> yours.

Russel, thanks for finishing the mail backend patch! Jacob's notes on
the ticket sound very reasonable to me - please let me know which of
them you'll address before merging. I'd be happy to  provide a patch
for anything remaining.

Andi

>
> Thanks!
>
> Jacob
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Last chance to object to new features

[Andi Albrecht]

On Tue, Nov 3, 2009 at 8:23 PM, Waldemar Kornewald  wrote:
>
> On Tue, Nov 3, 2009 at 6:37 AM, Russell Keith-Magee
>  wrote:
>> I've already integrated Jacob's comments into the code in my local
>> checkout. Actually, Jacob's comments pointed out an interesting code
>> cleanup: the File email backend is really just the Console email
>> backend pointing at a file object instead of stdout. As a result, I've
>> been able to delete a bunch of code by modifying the console backend
>> to accept an arbitrary stream, and making the file backend a subclass
>> of the console backend.
>>
>> I'll commit tonight (my time) once I have a chance to give the patch a
>> final review.
>
> Thanks a lot, Russell!
>
> Andi, could you please add your App Engine email backend to our test project?

I'd prefer to keep the App Engine email backends separate until we're
able to bundle a complete package that provides App Engine support for
Django.
Two backends (a synchronous and an asynchronous one) are available on
bitbucket: http://bitbucket.org/andialbrecht/appengine_emailbackends/

Andi

>
> Bye,
> Waldemar Kornewald
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Last chance to object to new features

[Andi Albrecht]

This just came up on IRC: in django.test.utils
setup_test_environment() the lines 46/47 are mixed up.

Here's a diff that fixes this issue:

diff --git a/django/test/utils.py b/django/test/utils.py
index a30bb7e..9d39eee 100644
--- a/django/test/utils.py
+++ b/django/test/utils.py
@@ -43,8 +43,8 @@ def setup_test_environment():
 mail.original_SMTPConnection = mail.SMTPConnection
 mail.SMTPConnection = locmem.EmailBackend

-settings.EMAIL_BACKEND = 'django.core.mail.backends.locmem'
 mail.original_email_backend = settings.EMAIL_BACKEND
+settings.EMAIL_BACKEND = 'django.core.mail.backends.locmem'

 mail.outbox = []

Sorry for pasting it here, but it's really just one line :)

Andi


On Tue, Nov 3, 2009 at 6:27 AM, Andi Albrecht
 wrote:
> On Mon, Nov 2, 2009 at 4:53 PM, Jacob Kaplan-Moss  wrote:
>>
>> On Mon, Nov 2, 2009 at 10:02 AM, Russell Keith-Magee
>>  wrote:
>>> A quick reminder - if you have any objections or feedback on #10109,
>>> the M2M refactor [1], I intend to land this patch in approximately 48
>>> hours.
>>
>> I've left a few comments in that thread, but they don't need to be
>> addressed pre-merge. Fire away!
>>
>>> Also, following some mailing list and IRC discussion [2], I'll be
>>> trying to land #10355 at the same time. This is the addition of the
>>> email backend API.
>>
>> I've left a few notes on the ticket. The only one that needs to be
>> addressed pre-merge is a simple design decision, and the final call's
>> yours.
>
> Russel, thanks for finishing the mail backend patch! Jacob's notes on
> the ticket sound very reasonable to me - please let me know which of
> them you'll address before merging. I'd be happy to  provide a patch
> for anything remaining.
>
> Andi
>
>>
>> Thanks!
>>
>> Jacob
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: django + memcached: problem with limit of 1 mb

[Andi Albrecht]

Items in memcached are limited to 1MB, see
http://code.google.com/p/memcached/wiki/FAQ#Why_are_items_limited_to_1_megabyte_in_size?


Andi

On Thu, Feb 18, 2010 at 8:34 PM, ramu...@gmail.com wrote:

> Does anyone know why django can't keep a data bigger, than 1 mb in
> memcached ?
>
> This is no big deal to cut big data to 1mb pieces before setting and
> merge this pieces after getting from memcached. And this algorithm can
> work transparently for users.
>
> --
> 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.
>
>

-- 
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: EmailBackends

[Andi Albrecht]

While discussing the implementation details of the email backends, Russel
came up with a nice view on this topic: "If you have highly specialized mail
requirements, then it makes sense that you should have a highly specialized
mail server handling." [1] If I recall it correctly the consenus was that
Django doesn't aim to provide a full-blown email service, but an easy to use
default method for sending mails. According to your initial post it sound
like your application has a special email feature to send out mass mails
using a queue. And high-volume mail processing doesn't sound like a default
case to me.

IMO the best solution for your use-case is to have two email backends. One
for the newsletter and one for any other mails generated by your
application. You can easily pass a connection parameter to the send_mail()
or send_mass_mail() function.

Andi

[1] http://groups.google.de/group/django-developers/msg/a86c5bf950e43d57

On Tue, Feb 23, 2010 at 1:08 AM, Mat Clayton  wrote:

> Sorry I probably didn't explain this properly. A composite backend is half
> the solution, the other part of the problem is deciding which backend to
> use. This decision in our case needs to be made where mail.send() is called.
> Either I could load in a custom backend here and replace the default one, or
> alternative pass some kwargs through send() to the send_messages() function
> in the backend, allowing the composite backend to choose
> the appropriate backend to use.
>
> Does this make more sense? As in this case I cant throw an Exception
> easily, as the backends wont fail, they just delay a lot, and ideally any
> backends used by a composite backend should be independent of each other.
>
> Mat
>
>
> On Mon, Feb 22, 2010 at 11:49 PM, Jacob Kaplan-Moss wrote:
>
>> On Mon, Feb 22, 2010 at 12:48 PM, Mat Clayton  wrote:
>> > Any thoughts on this as a change to the Email Backend system in django?
>>
>> I'm not sure why you'd need any changes to the backend system:
>> couldn't you easily create a composite backend class that tried to
>> send email through multiple backends? Here's my completely untested
>> stab at the problem::
>>
>>class IDontWanna(Exception):
>>pass
>>
>>def composite_backends(*backends):
>>class CompositeEmailBackend(object):
>>def send_messages(self, messages):
>>for backend in backends:
>>try:
>>backend.send_messages(messages)
>>except IDontWanna:
>>continue
>>
>>MyMultipleBackends = composite_backends(BackendOne(),
>> BackendTwo(), BackendThree())
>>
>> Jacob
>>
>> --
>> 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.
>>
>>
>
>
> --
> --
> Matthew Clayton | Founder/CEO
> Wakari Limited
>
> twitter http://www.twitter.com/matclayton
>
> email m...@wakari.co.uk
> mobile +44 7872007851
>
> skype matclayton
>
>  --
> 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.
>

-- 
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.