On Thu, 2009-04-02 at 09:15 -0700, Bill Konrad wrote: > Malcolm, > > I'm just following up on my last post.
A whole 12 hours after the previous one. I had a day away from mail. That happens sometimes. > I have gone over the django- > restapi library and would appreciate more guidance on the intended > direction of the project. As you suggested, following up on the > existing work there is a great way to get this feature to the public > this summer. It's already "to the public" -- it's been publicly available and maintained (brought up to date to run with Django 1.0) on Google code for a few years. There's even been a maintainer hand-over last year, indicating ongoing life and maybe one day, the people maintaining it will propose it for addition to django.contrib. This is one of my big problems with your proposal so far. I'm not seeing what you're bringing to the table here. I don't think working further on django-restapi is a Summer of Code project. I don't think it's a candidate to be merged into django.contrib (yet) either. I also don't have particularly strong feelings about things that are needed, since I don't really use it. I follow the code changes, but don't use it in my applications. My REST apis don't map directly to models and there's lots of intermediate processing going on, so I use normal Django views to do the work. There's an issues list at Google code and a mailing list with archives (django-rest on Google Groups) that is low enough volume you could look through there for ideas. I like the broad structure used in django-restapi -- Andreas did a good job of trying out a bunch of possibilities to come up with something that is actually an aid, rather than an obstruction, for models. However, this is really a third-party project, not something that is improving Django's core, so it's out of scope for Summer of Code. Working on duplicated work just so that it's a Summer of Code project isn't a valid technical reason to do something, either. This keeps coming back to my questions about what modifications are needed to solve actual problems in core that makes this a worthwhile project? I haven't heard anything from Jacob about what he thought he discussed with you on this issue. Your version of it is so far a bit shy on specifics and it looks like you're still hunting around for "do something cool with REST" project. Unfortunately, asking me for ideas isn't going to help you, since I've already indicated that apart from a couple of small resolver changes and short utility functions to mark up which resolver to use for a function (the former being appropriate for core in 1.2, the latter maybe or maybe not), I don't see much extra that is needed. We already have a fairly viable third-party application that people can contribute to if they want model -> front-end RESTful-style API (django-restapi). It's not something I've found myself needing, since writing an appropriate API for the code I have in front of me isn't that hard. So, once again, I'm forced to ask -- and this is something you really need to answer if you're going to come up with a proposal: What problems are you trying to solve that aren't already possible? Why do these problems need core changes to Django? Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
