Malcolm, I'm just following up on my last post. 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.
Thanks, Bill Konrad On Apr 1, 12:19 am, Bill Konrad <bkon...@gmail.com> wrote: > Malcom, > > I took a look at django-restapi and it seems like a great start. > Having been the mentor for the first run at it, what features would > you like to see added? If you have a minute, I think that would > definitely serve as a great guide. > > Thanks, > > Bill Konrad > > On Mar 31, 9:15 pm, Malcolm Tredinnick <malc...@pointy-stick.com> > wrote: > > > On Tue, 2009-03-31 at 17:31 -0700, Bill Konrad wrote: > > > First off, thanks for taking the time to read through it and give so > > > much feedback. > > > > Please let me clarify one thing. If you read the above as a proposal > > > than it wouldn't have seemed much like a proposal. I was only > > > outlining what a REST API module (I know you don't like that naming) > > > would need to provide. The proposal goes much further and contains > > > more detail. > > > Well, you said you had created a problem statement and I assumed that > > mail was it. Apparently not. It's a bit confusing as this whole proposal > > to do something for Summer of Code hinges on there actually being a > > problem to solve and a solution that solves it, not the fact that REST > > exists. > > > > The reason that I refer to it as a module and think there is more to > > > this than just an architectural style is that by providing an API > > > "service" that models can be registered with (think django-rest- > > > interface from 2007) a lot of the details can be ignored by someone > > > who is not interested in writing a full API from scratch. > > > Then please stop calling it a generic REST API. Because it's not. It's > > an interface to expose models. A generic REST API requires the full > > power of Python because, as I've already noted, it's an orthogonal > > concept to what is stored persistently. We provide a way to retrieve > > arbitrary data -- view functions and the ORM. You can't hope to make it > > any simpler than that for the general case. > > > > The > > > objective would be to let the developer define which data can be > > > accessed through the API, who can access it and have most of the > > > internal details handled for him. > > > So is this another pass at the 2007 project again? Why not contribute to > > django-restapi instead and keep that going along? I know why that > > project got as far as it did and what the limitations and strengths of > > it are (since I was the mentor for that student). For a > > model-presentation API, it's going in the right direction and people are > > using it. > > > The devil is in the details here and the worthiness of a proposal along > > these lines very much on what you are thinking requires changes in > > Django's core. I think the answer to that is "very little". Which then > > leads me to wonder about what you're proposing to do. > > > [...] > > > > Does that help clarify what I wrote a bit? > > > Not really, because I still don't know what you're proposing to do and > > the specifics are important for a Summer of Code project. > > > 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 -~----------~----~----~----~------~----~------~--~---
