> Lets look at it from a performance perspective. > > 1- 1MB datastructure - which unit of data (leaving files outside) > should be bigger than 1mb? IMO that's a badly design datastore. > 2- 1000 query limit, which user is going to want 1000 results? > 3- Short CPU, it is common knowledge that a user will go away from a > page after 3 seconds of loading. so in order to eliminate this > bottleneck you use catching, after all if it's intensive to compute > it's worth catching. > 4- Quotas in general, not even google has enough machines for us to waste. > 5- Admin, a django junkie complaining for the lack of UI
Let's stop the slogans, and get down to a real discussion here. Discussions are useful. This post misrepresents the original article needlessly and this does not add to the discussion at all. Use-cases for 1 MB were given, and there are plenty more. It is not sufficient that you can use S3, because the over 1 MB file may well be autogenerated (like a downloadable PDF or Excel or XML file). The query limit was given specifically in combination with the lack of expression power to select the records. Nobody wants to return 10.000 records to the browser, but you have to be able to get the 50 records you do want to return. True, some applications know upfront what the exact key will be, but some applications need more dynamic querying. Also, the limit is hurtful because currently MapReduce can only be implemented as a series of successive calls. Likewise, the CPU was not discussed in the context of rendering a standard user page but in the context of background processing and/or report building. Quota's were discussed with lot of understanding, but also a lot of nuance. How do you actually respond to the remarks made? Let's get down to real applications. Admin again was not about being able to use Django, but about how to do data transformation on your database. Do you think Google would be able to rebuild its index, or do any other part of its magic, without MapReduce? Admin is about the ability to prepare things before the user needs them, so that yes you can respond in subsecond turnarounds. > The only concern where I agree is file upload, we do need a facility > to uplod videos or pdf or images or whatever we want, but that is > being worked out, same with SSL. Look, Google has declined to provide forward looking data. Yes, I was at Google IO and they ARE good guys and I believe them when they express their best intentions to meet specific targets (back then, at the beginning of the year). But not providing an official calendar means they are not putting their foot down, essentially that they don't know themselves. Google is asking us to use what is there, and only what is there (not that I wouldn't like a calendar, and that would reframe this discussion completely - but it simply isn't there). And there is little tangible evidence that warrant the faith that they will in fact have a big bang improvement within what has now become a really very short time frame. So my guess is that we'll see substantial delays relative to what was said back at Google IO. And I like Google App Engine very much. Really. And yes, I do build real applications on top of it. And I do believe that many of their limitations stem from the need to scale. I feel that still leaves plenty of room for discussion, and especially for this blog post that makes a lot of very good arguments. Plus the author clearly uses and understands GAE, uses Python, isn't complaining about the designers philosophy. The good news is that by the end of *2009*, the world might be really interesting with GAE, and with competing platforms driving each others features. Filip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
