Re: CSRF proposal and patch ready for review

[Luke Plant]

OK, you convinced me.  I really would rather this wasn't baked in, but given 
the migration issues and the fact that it is security related, I guess I can 
stomach it.

I've updated the patch [1] to move things to builtin functionality.  I also 
had to fix some bugs to get the csrf_protect decorator working for methods, 
which are in trunk already.

I've left most of the code itself under django/contrib/csrf because:

 1) backwards compatibility with people importing the middleware
means we have to leave django/contrib/csrf for some things
anyway.
 2) In this case, I don't see any great advantage in having stub modules
which just import other stuff for backwards compatibility
 3) I really can't be bothered to change all the imports
at this point in time!

I moved the template tag itself to core code, because it was causing import 
cycles otherwise, and there are no backwards compatibility issues, nor does it 
add any actual imports of contrib code to core.

I think the patch now addresses all your/our concerns:

 - decorator on all contrib view functions that need it.
   I'm pretty sure I got them all, but I only decorated the ones
   that actually need it (i.e. use POST), and I only added it
   on the 'source' function (e.g. auth.views.password_change and not
   AdminSite.password_change) because otherwise
   you end up decorating many times.  I also added the decorator
   in AdminSite.admin_view, which will be a catch-all for all
   admin views (provided users are using AdminSite.urls)

 - the view middleware is still on by default.

 - csrf_token is in builtin templatetags

 - csrf context_processor is hard coded into RequestContext

 - tests 'fixed' with very little work.

I fixed the tests by a custom attribute on request objects that tells the 
middleware/decorator to not actually reject requests.  This is better than 
disabling completely, because it means that the middleware will still send 
cookies etc., and it's always good to have tests as close as possible to the 
real code.  The test client adds the custom attribute to HttpRequests after it 
has created them.  I had to add the attribute in one other place in the code 
as well - a test that was manually calling a view function that had 
csrf_protect applied.

This method of fixing tests was also the best for testing the CSRF middleware 
- globally mocking the middleware out would have made it hard to test the 
middleware itself!

Docs are all updated, all tests passing etc.

If people are happy for this to go in, it would be very helpful if other 
people could have a go updating their apps and give the general docs/upgrade 
instructions/tutorials a good check after I commit it.  I can't easily do 
checks like that, because I just won't spot the holes after having the code in 
my head for so long.

The only thing left is a nicer render_to_response shortcut for using 
RequestContext, which is a refinement we can add later.

Regards,

Luke

[1] 
http://code.djangoproject.com/attachment/ticket/9977/csrf_template_tag_r11587_1.diff

-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: decorator_from_middleware change

[Luke Plant]

On Monday 21 September 2009 20:27:50 Jacob Kaplan-Moss wrote:
> On Mon, Sep 21, 2009 at 1:21 PM, Luke Plant  wrote:
> > However, decorator_from_middleware is a pain, since it doesn't always
> > return a an actual decorator, for "historical reasons".  I need to change
> > this to fix the bug.  Is anyone against this?
> 
> No, I think this is precisely correct. I've been meaning to do exactly
> what you're proposing for a while myself; just haven't gotten around
> to it.
> 
> > decorator_from_middleware isn't actually documented anywhere
> 
> I actually avoided documenting it because it's broken. Once you fix
> it, we should (i.e. I will, if you don't have time) document it.

I've committed my change [1], and also replaced _CheckLogin with my method [2]
(it was essentially the same method, just generalised).

I haven't added any docs, because I'm not sure it's perfect yet (and also 
because I am lazy and I was mainly working on something else, this just got in 
the way).  In the 'normal' case where you don't need to pass any args to the 
middleware, it is exactly the same (but works for decorating methods now).  In 
the abnormal case, you have to use decorator_from_middleware_with_args, which 
is a pretty ugly name, if explicit.  I don't know if you had other ideas about 
what to do with this.  Changing that name is easy, it's only used by 
cache_page.

Luke

[1] http://code.djangoproject.com/changeset/11586
[2] http://code.djangoproject.com/changeset/11587

-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Tobias McNulty]

On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
>
> You also mention that there are a number of other implementations, but
> you haven't really given a compelling survey or analysis of the
> alternatives - you've just blessed one in particular. Why?
>

I started a wiki page comparing some of the different options out there:
http://code.djangoproject.com/wiki/SessionMessages

Feel free to update with (your messaging backend here).

Tobias

--~--~-~--~~~---~--~~
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: Session/cookie based messages (#4604)

[Tobias McNulty]

On Sun, Sep 20, 2009 at 6:13 PM, Chris Beaven  wrote:

> Having some kind of defacto cross-request notification system makes
> sense; it's a very common usage pattern.
> Attaching these kind of messages to a User instance is wrong: there is
> not an enforced one to one correlation between a user and a session
> [1], and you can't notify anonymous sessions.
>

Exactly.  What makes this such a pressing issue for me is that the current
user.message_set implementation directly *encourages* the (bad) habit of
attaching messages to a user, without offering a more extensible
alternative.  There are many situations in which the message_set
implementation breaks down and reasons why a more robust standard is needed,
and needs to be blessed by the core developers.  To mention a few:

1) it's not possible to create messages for anonymous users
2) if the same Django user is logged in twice on different computers
simultaneously, they see each others' messages
3) as Chris mentioned, messages may get wiped even if they're not actually
displayed to the user
4) high-load sites want to avoid the unneeded database or cache usage
5) since the built-in implementation is broken and no standard exists,
reusable apps don't know what system to use and hence cannot rely on
providing session feedback
6) it's debatably a more common problem than anything else in contrib: A
site that doesn't allow users to login (hence no contrib.auth) may still
need session-specific feedback.

Implementation-wise, it's also a very simple problem.  Sessions and cookies
will cover 95% of the use cases at hand.  Both are necessary for a couple
reasons: cookies may not be large enough to store all messages, and the
session may be more expensive to use (and hence should be avoided if
possible).  For the remaining 5%, it's incredibly easy to write a custom
backend in at least one of the messaging/notification options out there.

In my mind what we need now is more eyes on the code and more feedback about
the pros and cons of each option out there.  Perhaps something as simple as
a wiki-based table would do.  I've previously summed up the criteria for
what I think would make a solid notification engine and only found one app
that did it, but that may have changed and there are probably options out
there that I don't know about.  My post and the feedback I received can be
found here:

http://www.caktusgroup.com/blog/2009/06/19/towards-a-standard-for-django-session-messages/

On a side note, I talked with Simon about this at the sprints and he made
the point that we also need a genuine, cryptography expert-approved
cookie-signing utility in the core, which this messaging/notification app
would ideally use.  The issue, as I understand it, is that we want to be
certain pickling misc. objects and sticking them in a cookie is actually
secure, and not rely on (with all due respect) [some random cookie signing
implementation].

Tobias

--~--~-~--~~~---~--~~
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: decorator_from_middleware change

[Jacob Kaplan-Moss]

On Mon, Sep 21, 2009 at 1:21 PM, Luke Plant  wrote:
> However, decorator_from_middleware is a pain, since it doesn't always return a
> an actual decorator, for "historical reasons".  I need to change this to fix
> the bug.  Is anyone against this?

No, I think this is precisely correct. I've been meaning to do exactly
what you're proposing for a while myself; just haven't gotten around
to it.

> decorator_from_middleware isn't actually documented anywhere

I actually avoided documenting it because it's broken. Once you fix
it, we should (i.e. I will, if you don't have time) document it.

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

decorator_from_middleware change

[Luke Plant]

Hi all,

I need to fix #6371 [1], and I've found a nice way to do it (something like 
[2]).

However, decorator_from_middleware is a pain, since it doesn't always return a 
an actual decorator, for "historical reasons".  I need to change this to fix 
the bug.  Is anyone against this?

decorator_from_middleware isn't actually documented anywhere, but I'm guessing 
it might be used outside of the Django code base.  I want to change it as 
follows.

For decorators like gzip_page, everything works as normal:

  gzip_page = decorator_from_middleware(GzipMiddleware)

The only difference is that gzip_page is now a true decorator.

For decorators which require arguments given to the middleware, you will now 
need to use decorator_from_middleware_with_args.

I will manually fix the one decorator this breaks (cache_page) to provide 
backwards compatibility with the published documentation.

Does anyone object to this change?  It makes fixing #6371 a *lot* easier.  In 
fact I can't actually get my head around how to fix it at all without the 
change.

Luke


[1] http://code.djangoproject.com/ticket/6371
[2] http://stackoverflow.com/questions/1288498/using-the-same-decorator-with-
arguments-with-functions-and-methods/1288936#1288936

-- 
Parenthetical remarks (however relevant) are unnecessary

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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.core.urlresolvers reverse, args and kwargs (Ticket 8764)

[vegas]

> However, be prepared for the outcome that your code may be rejected
> and thrown away. In this case, the code is serving as a working
> implementation of your proposal, and we still haven't been convinced
> of your proposal. Just writing the code doesn't mean it will
> automatically get accepted.

I'm fine with that. Would prefer to engage in some more detailed
discussion before writing the code though.
> > Are there any pre-existing benchmarks on the url resolution process?
> > Looking in trunk/tests, I see
> >http://code.djangoproject.com/browser/django/trunk/tests/regressionte...
> > which looks to mostly be correctness tests, not performance tests.
>
> You are correct that there aren't any performance tests. The
> performance test is not allowing O(2^n) algorithms into the
> URLresolver in the first place :-)
So presenting some performance benchmarks showing equal or better time
with the current implementation,
along with a complexity analysis that shows that it isn't an
exponential time algorithm would help my case here?

I'm pretty sure that the solution I outlined earlier in this thread
differs from the current algorithm by only a constant factor, and had
another idea for how to do this last night that I think my have lower
algorithmic time complexity than what is in the 1.1 release.  I'll
write those up before writing my code and send them along.

Cheers,

Alex
> 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
-~--~~~~--~~--~--~---

What happened with #7048

[Léon Dignòn]

Since I really *love* the idea and already use the RemovableFileField
snippet, I'd like to know what happened with #7048?

Will we keep using the snippet, or are there plans to port them to
django? The last comment is nearly one year old.

-leond
--~--~-~--~~~---~--~~
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: Distorted layout of this group in Google Groups

[Léon Dignòn]

Not for me, but ?hl=en did the trick.
Thanks

On 21 Sep., 17:12, Dougal Matthews  wrote:
> 2009/9/21 Karen Tracey 
>
>
>
>
>
> > On Mon, Sep 21, 2009 at 10:53 AM, Léon Dignòn wrote:
>
> >> Hello,
>
> >> Am I the only one with this problem? It's annoying because it covers
> >> all the topics and also text of discussions.
>
> > This appears to be some sort of google groups problem, that only affects
> > some people some of the time (I've not seen it at all).  See:
>
> >http://groups.google.com/group/is-something-broken/browse_thread/thre...
>
> Funnily enough I seen the problem on that link itself but reloading the page
> (F5) sorted it out for me.
>
> Dougal- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
--~--~-~--~~~---~--~~
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: Distorted layout of this group in Google Groups

[Dougal Matthews]

2009/9/21 Karen Tracey 

> On Mon, Sep 21, 2009 at 10:53 AM, Léon Dignòn wrote:
>
>>
>> Hello,
>>
>> Am I the only one with this problem? It's annoying because it covers
>> all the topics and also text of discussions.
>>
>>
> This appears to be some sort of google groups problem, that only affects
> some people some of the time (I've not seen it at all).  See:
>
>
> http://groups.google.com/group/is-something-broken/browse_thread/thread/c73ae586c6fcef48/
>
>
Funnily enough I seen the problem on that link itself but reloading the page
(F5) sorted it out for me.

Dougal

--~--~-~--~~~---~--~~
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: Distorted layout of this group in Google Groups

[Karen Tracey]

On Mon, Sep 21, 2009 at 10:53 AM, Léon Dignòn  wrote:

>
> Hello,
>
> today I browsed to the group django-developers in Google Groups. The
> navigation bar with the adverts, which is normally on the right side,
> covers all the discussion topics on the left. The layout is broken,
> but only in this group. In django-users everything is fine.
>
> Am I the only one with this problem? It's annoying because it covers
> all the topics and also text of discussions.
>
>
This appears to be some sort of google groups problem, that only affects
some people some of the time (I've not seen it at all).  See:

http://groups.google.com/group/is-something-broken/browse_thread/thread/c73ae586c6fcef48/

Karen

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

Distorted layout of this group in Google Groups

[Léon Dignòn]

Hello,

today I browsed to the group django-developers in Google Groups. The
navigation bar with the adverts, which is normally on the right side,
covers all the discussion topics on the left. The layout is broken,
but only in this group. In django-users everything is fine.

Am I the only one with this problem? It's annoying because it covers
all the topics and also text of discussions.

-ld
--~--~-~--~~~---~--~~
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: CSRF proposal and patch ready for review

[Russell Keith-Magee]

On Sun, Sep 20, 2009 at 2:57 AM, Luke Plant  wrote:
>
> On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:
>
>> On Fri, Sep 18, 2009 at 6:09 AM, Luke Plant  wrote:
>> >  If the target of a  is internal:
>> >   * add {% load csrf %} to the template and {% csrf_token %} to the form
>> >   * use RequestContext in the corresponding view.
>> >
>> > And that's it.
>>
>> ... once you've also got your INSTALLED_APPS, CONTEXT_PROCESSORS and
>> MIDDLEWARE_CLASSES set up correctly - and make sure you have, because
>> if you haven't you're going to get weird errors - or worse still,
>> accidentally disable CSRF protection.
>
> Fair point - I was explicitly talking about the *day-to-day* usage at that
> point.  For the other things, the errors aren't quite so inscrutable any more
> - the 403 page looks like this now:
>
>  http://lukeplant.me.uk/uploads/django_csrf_403.html

I agree that this makes the reasons a lot clearer, but I stand by my
criticism that it's still a metric buttload of instructions just to
make a basic form submit.

My concern here is that every time you add an item to a list of
migration instructions, you increase the possibility that something
can go wrong. In turn, this increases the likelihood that a potential
convert will get frustrated and declare that "Django sucks" - or
worse, that an existing convert will declare "WTF" and go somewhere
else. In this case, the thing that is going to go wrong is "submitting
forms", which is pretty much the bread and butter of a web framework.
IMHO, anything we can do to limit the number of things that can go
wrong, the better.

> ...but is it really our fault if people disable the protection? I guess to the
> extent that we've made it difficult to get right, or more tempting to do it
> wrong, it *is* our fault.

I'm not sure that this is a distinction that users are going to make
when their site gets hacked. I would bet money that regardless of the
cause, Django will wear the blame. If the problem was caused by the
end user disabling CSRF protection against Django's advice, then it
will be Django's fault that it was possible to disable it at all.

>> So - is there anything we do to make the template tag more palatable?
>>
>> I think we can - and you've already shown how:
>> > In fact, if you simply want to fix contrib apps, SafeForm is a massively
>> > over- engineered solution, as there are *much* less invasive ways to do
>> > it.  All you need to do is:
>> >  1) add the CSRF template tag to builtins and use it in templates.
>> >  2) add a @csrf_protect decorator on views.
>> >  3) hack RequestContext so that it always includes the CSRF context
>> > processor.
...
>> >
>> > All contrib apps use RequestContext anyway, so the changes needed for
>> > that method would be tiny, with no changes to settings.py required.
>
> OK, I agree that this solution has some nice features, but let's be realistic
> about its failings:
>
> 1) changing RequestContext so it always includes the CSRF context processor is
> ... 'cowboy', as I think Simon would put it :-)  I wasn't actually suggesting
> that as a real proposal.

I was :-) Or rather, I'm not thinking about this as an 'always
included context processor', but as a core piece of functionality that
we should bake into RequestContext. CSRF is a very big problem at the
core of rendering forms. Why not make CSRF protection a core part of
the RequestContext contract?

> 2) We would still have to fix all the tests, because we can't just turn the
> decorator off.  There are also the tests that we can't fix, i.e. where other
> people have customised contrib apps in various ways and written tests against
> the views.  I mentioned this in my most recent reply to Simon.  I'm not so
> bothered about having to fix ours, it's other people's that worry me, and
> the DRY violation - baking it in like this means that every test of a POST
> view is now concerned with CSRF.
>
> I can think of some hacks to avoid fixing tests (ours and other peoples):

Agreed that we shouldn't require wholesale updates to test suites.

The test suite already does some setup/teardown to make a testable
environment - for example, swapping out the SMTP outbox - removing or
mocking CSRF protection could easily fit into this box.

> I think the lazy instinct which makes me not want to fix even our own tests is
> a healthy instinct at root...but I don't know how to address it best.

Agreed, on both counts.

> Seriously, another option is to make AdminSite.check_dependencies require the
> middleware.  It already has checks for INSTALLED_APPS and
> TEMPLATE_CONTEXT_PROCESSORS - i.e. the admin will just refuse to work if you
> don't have these things set up correctly to include the CSRF stuff.  I
> deliberately avoided adding the CSRF middleware to that list because I wanted
> it to be possible to just disable the middleware for debugging/testing
> purposes.  I'm not sure that's so necessary now - if we 

Re: CSRF proposal and patch ready for review

[Luke Plant]

On Saturday 19 September 2009 16:56:52 Russell Keith-Magee wrote:

> So - let's have both. A middleware enabled by default protects the
> rest of the views. However, we can also have a view decorator lets us
> protect admin (and other contrib apps) explicitly. If users disable
> the middleware, admin remains secure. If users fail to follow the
> migration instructions correctly, admin remains secure. Users like
> Simon that were tormented by middlewares when they were younger ( :-)
> ) can disable the middleware and use the decorator liberally
> throughout their own projects; the worst possible outcome here is that
> one of their own views is insecure - admin is unaffected.
> 
> The middleware and view can easily be made to play nicely together -
> there's no need to check the token twice, so make the middleware set a
> flag on the response object that marks the content as CSRF-checked; if
> the decorator sees that flag, it doesn't need to duplicate the check.

Another advantage of the middleware + decorator solution is that sometimes 
there might be a legitimate case for turning off the middleware globally e.g.:

 - if for some reason there are no POST forms, and never will be.
 - if all POST interaction is done using AJAX
 - if the user has implemented their own solution for CSRF for 
   their own apps.

In this situation, it's nice if the developer can turn off the middleware and 
still have the admin protected.

In trying to implement this, I came across the problem that the same decorator 
can't be used for methods and functions, and I need to decorate some methods 
of AdminSite. (AdminSite uses never_cache directly on methods quite a bit, but 
this only works by accident - never_cache doesn't use the view function 
arguments (e.g. the request object), otherwise it would fail).  Does anyone 
have a nice solution to this?

Regards,

Luke

-- 
"Outside of a dog, a book is a man's best friend... inside of a dog, 
it's too dark to read."

Luke Plant || http://lukeplant.me.uk/

--~--~-~--~~~---~--~~
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: SoC merge plans?

[Russell Keith-Magee]

On Mon, Sep 21, 2009 at 4:28 PM, Waldemar Kornewald
 wrote:
>
> On Sep 20, 1:54 pm, Russell Keith-Magee 
> wrote:
>> Based on the discussion Alex and I had at the sprints, query_class()
>> will still exist, but it will play a slightly different role -
>> essentially, it will be more important for non-SQL backends than for
>> Oracle support.
>
> Could you please explain what you have in mind, so I can comment on
> it?

While I appreciate the enthusiasm, I need to repeat what I said
originally - this is a fairly big refactor of the way the SQL backend
handles queries, and I want to make sure it's right before we inflict
it on the world. This includes abstract discussions of what might be.

Give me a chance to flesh out the ideas that I have and make sure that
they work for the problems we already have (Oracle and GIS). Once I'm
sure we have got those issues under control, we can tackle the new
problems like supporting non-SQL backends.

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: Looking for a project

[Russell Keith-Magee]

On Sun, Sep 20, 2009 at 11:29 PM, Daniel Watkins
 wrote:
>
> Hello all,
>
> As part of the third year of my computer science degree (at the
> University of Warwick), I need to complete an individual project.  I'd
> quite like to use this to do something for Django.  The project is meant
> to be done entirely individually, which means that something that works
> as a standalone app (rather than being a branch of Django itself) would
> be preferable.
>
> The project needs to be completed between the beginning of October and
> April, with about 5 hours a week being spent on it.
>
> I have a few half-formed ideas of my own, but if anyone else has an idea
> of what I could do, I'd like to hear about it.

First off - this sort of question would be better suited if you asked
on Django-users. Django-dev is for discussing the development of
Django itself; django-users is for general user queries.

Admonition aside: it might help if you narrow the scope of your
question for us. This is for an academic project - what constraints is
the university placing on the project? Do you need to demonstrate
technical competence in some particular area? Do you want/need to use
any particular set of technologies? Is project planning and management
more important than technical issues?

Depending on your exact project needs, there are any number of options
available.

1) Build a pluggable app that implements some interesting piece of
functionality.

This seems to be where you are focussed at the moment - build a
pluggable application that implements some useful feature, such as
webmail or a calendar. There are any number of options here; my only
advice is to make a good survey of the state of the art before you try
to duplicate an existing project. The apps integrated with Pinax are
probably a good place to start looking. It may also be worth asking
the Pinax guys to see if they have any wishlists for new apps.

This sort of project is good if you're looking to prove high-level web
programming skills plus JS+HTML.

2) Implement something that is a standalone feature request for Django.

You could also look at utilities that would be useful to Django
without actually being part of Django itself at present. For example,
there is a long standing feature request to allow for more
customization in the serializers. If your design and code is good, it
might eventually end up in the Django core, but in the interim, you
could tackle this as a standalone project.

This sort of project would be good if you need to prove API design
skills, and want to stick to Python as an implementation language.

3) Implement a backend for one of Django's public APIs.

Django exposes a number of backend APIs that are designed for
end-users to extend. For example, consider the database backend. IBM
DB2, MSSQL and SQLAnywhere are all supported as external projects with
no involvement or interaction with the Django core.

So which backend to implement? Well, at this point, we have all the
common relational databases covered, but we don't have a good answer
for non-relational databases. We have someone working on the Google
AppEngine backend at the moment; if you were to pick another datastore
(say, CouchDB, Cassandra or MongoDB), you could use the get up to
speed with an emerging web technology, plus be contributing in a
meaningful way to the Django community, without actually working on
the Django core itself.

This sort of project would be better suited if you need to prove
capabilities in low-level technologies and APIs. However, it might
also be a little ambitious given your time constraints. You'll have to
judge this one for yourself.

So - there are lots of options. It really comes down to what you're
interested in, and what you're trying to achieve with your project.

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: Looking for a project

[veena]

Hello,
I propose the "universal" Task Queue app similiar to one at Google App
Engine http://code.google.com/appengine/docs/python/taskqueue/

Universal means to be able to run it on any hosted server where cron
is available.


Vaclav


--~--~-~--~~~---~--~~
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: SoC merge plans?

[Waldemar Kornewald]

On Sep 20, 1:54 pm, Russell Keith-Magee 
wrote:
> Based on the discussion Alex and I had at the sprints, query_class()
> will still exist, but it will play a slightly different role -
> essentially, it will be more important for non-SQL backends than for
> Oracle support.

Could you please explain what you have in mind, so I can comment on
it?

For example, I'm not sure if query_class() is such a good solution for
non-SQL backends. While it would work, query_class() makes things
unnecessarily complicated because you have to keep track of and cache
all your generated subclasses and the Query base class. Also, you'd
have to pass class names around (e.g., query_class('UpdateQuery'))
because non-SQL backends will have to use their own subquery base
class (e.g., nonrelational.subqueries instead of sql.subqueries), so
this makes query_class() not a great solution.

Wouldn't it be nicer to just return a complete module (query_module())
which contains all overridden classes? This way you won't have to
cache anything because the module is automatically cached by Python
and you don't need to check for subquery class names in the function
because you return all classes at once via the module. By default, the
module would just be django.db.models.sql.

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