On Thu, Oct 9, 2008 at 6:09 AM, Filip <[EMAIL PROTECTED]> wrote: > > >> 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). > Ok that seems like a valid use case, I'll give you that point when you are generating a file on the fly you may get stuck with the 1MB limit. But keep in mind the "big file serving" Guido talks about still apllies to this use case.
> 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. > will you post an example where you need 1000 results to then narrow it down to 50? this seems to me like a "joins" design which is something you shouldn't be doing in datastore, it has been discuss several times that you shouldn't use datastore as a relation database. You may disagree if you are strong on SQL but denormalization is the first step of scalability. > 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. > Which are facilities that aren't out on the engine, so you can't critize an interface that was build to serve pages as a bad background processing tool, it will be like complaining about how bad that Italian restaurant is at making Hamburgers. > 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. > I'm a minimalistic at heart, and I strongly believe that any app running that is getting over the head of it's quota is because it isn't efficient enough, with the sole exception of the max page views in which case google has and will increase that bar for the applications that demand it. Again from the talk, the top 5 applications running on GAE have had their quotas raised because they really need it not because some script kiddie is loading half his datastore into memory on every request. > 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. > what? the Admin (in a django concept) is a way to fix error in the data and sometimes input data by advanced users, you shouldn't be manipulating a db structure from a GUI, that is why we have migration scripts and so many project dedicated to them. >> 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. Well that's a social issue, and I wasn't there so I don't have the first hand experience. But do keep in mind the same thing could be said about any product. But I'm not the person to answer this, they are. > > 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. Isn't this what we are doing? my point is that most of the complains in this group come from people that want GAE to be X,Y and Z without any criteria, specially with the limits discussion, most people say you are google you are huge give me your resources for free, instead of sitting down with their code and fix it. > 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. > Maybe, my crystal ball is clowdy today. > 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 google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
