Another "community voice" contribution on this thread...

I am of the opposite opinion.  I think it would be better for Django as a whole 
if django.contrib approached zero.  In fact, I would have no problem with 
seeing it go away completely and promote auth and sessions to core but done in 
a way that is pluggable.  The reasoning behind this opinion is that it leaves 
the surface area in the project smaller to maintain and it's really not that 
hard to add a sorl-thumbnail external app to a Django project.  Furthermore, it 
provides more freedom for these apps to mature and develop at their own pace.

I realize I could very well be in a minority opinion here, but thought I'd 
throw it into the mix nonetheless.


On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:

> I have absolutely no pull in decision making, but maybe my message will count 
> towards a "community voice".
> 
> I think that including an image thumbnail package that integrates into the 
> database as easily as sorl.thumbnail and easy_thumbnail are is a great idea.  
> From what I can tell, sorl.thumbnail was the de facto standard for getting 
> thumbnails in to Django, and I think it has just as much of a place in Django 
> contrib as some of the other contrib apps do.  I don't think it belongs in 
> the core, but contrib seems like an excellent place for it to go along with 
> the other batteries in the pack.
> 
> On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
> I have no data to support the following assertion, but it's not too
> unreasonable: More people probably need thumbnail images than they
> need comments. Comments are most used on blogs, whereas thumbnails can
> be used on blogs, e-commerce, photo hosting, social networking,
> project management, et al. It's not to say that we don't need
> "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
> 
> 
> On Sep 15, 11:32 pm, "David P. Novakovic" <davidnovako...@gmail.com>
> wrote:
> > Actually, that really did sound negative. Sorry :)
> >
> > Is there a trac ticket open to address this issue? Generally it'd be
> > better to get discussion happening over a ticket and if there are
> > serious issues that need to be addressed then they can be discussed
> > here.
> >
> > I know it'd be nice to get things like easy-thumbnails accepted into
> > django.contrib , but the truth is that this probably falls outside of
> > things that that should be in contrib. Contrib isn't really an easier
> > way to get stuff into django, it still has to satisfy a bunch of
> > conditions like the rest of the code in the core.
> >
> > The real question is not "can it be included?" but why is it a problem
> > that this is a third party lib at the moment? Is there a strong case
> > that it be better if it was part of django core or does it do its job
> > just fine the way it is now?
> >
> > David
> >
> > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
> >
> > <davidnovako...@gmail.com> wrote:
> > > I don't want to sound negative, but answering your own question before
> > > anyone else can doesn't change the answer ;)
> >
> > > D
> >
> > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma <baxterstock...@gmail.com> 
> > > wrote:
> > >> Is there any plans to 
> > >> incorporatehttp://github.com/SmileyChris/easy-thumbnails/
> > >> into django.contrib? I have seen so many apps/libraries come into and
> > >> go out of existence (http://code.djangoproject.com/wiki/ThumbNailsfor
> > >> instance mentions sorl-thumbnails which is no longer being developed).
> > >> I just turned the key with easy-thumbnails and voila. It's like magic,
> > >> but not. It's easy enough to see what's going on behind the scenes.
> >
> > >> This is something that, with the help of the core and other
> > >> contributors, could be really great. It works for me as it it is, but
> > >> it may not work for a more "enterprise" application that uses S3, etc.
> > >> It might not be highly efficient (I wouldn't know). It might have bugs
> > >> that I just haven't noticed yet. I'm mentioning all of this because I
> > >> know somebody will say, "Why move it into Django if it's doing just
> > >> fine as a separate project?". After experiencing the bliss I thought
> > >> I'd drop a line here about it, and see what you guys thought.
> >
> > >> --
> > >> 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 
> > >> athttp://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.
> 
> 
> 
> 
> -- 
> Brian O'Connor
> 
> -- 
> 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.

Reply via email to