Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> do what we can in terms of exposing APIs to make their job easier.

Isn't that exactly what Simon is suggesting above?

He's not saying Django should provide its own implementation of a background queue, he's saying it should provide a base API which could be implemented by any number of backends, of which assuredly Celery would be one -- just as happens now with cache backends.

I agree with Simon and the commenter above, this would be a great addition to Django. I think it fits with the Django "batteries included" philosophy -- in this day and age, a background queue is practically a requirement for anything but the most basic web app. It also encourages standalone Django application developers to make use of background queuing without fear of forcing a specific implementation on users.



Yes, that's exactly what I meant. Like you say: today, a background queue should be part of the default stack for a web (just like a template engine, database, session storage and a cache have been in the past - components which Django has provided since day one). No need to re-implement celery, but encouraging the Django ecosystem to embrace offline queues (and letting reusable apps know that they can push tasks in to an abstract queue of some sort) would be very healthy.


I agree that this would be a great addition to Django. Celery may not fit everyone's needs. I would rather have something lighter weight for dev.


I wasn't suggesting have a generic queue API in Django, I was suggesting any APIs needed to enable that to live outside Django entirely, whether that's better hooks into transactions (e.g. so I can wait until a DB transaction is committed to fire the task item) or something else.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: