<black-hat> I would like to echo Aral's post. Language wars generate noise, not analysis. It's no surprise that the top four issues *by a mile* are just adding language ABC. It is depressing that people are working on that at the expense of other things.
Admittedly, I am assuming that providing a complete application platform is the primary goal of GAE? More languages at this point hints that the goal is to provide multiple incomplete application platforms. Not supporting asynchronous processing is an enourmous hole, and to not have it on the roadmap, well, it almost seems like team members are making their own decisions about what they want to do :). </black-hat> <white-hat> I understand that as a business, you want the largest user base, and supporting PHP or Java is going to greatly increase that - but you are creating a rod for your own back by branching out in this way before the platform offering is compete. The pressure to get any new features right the first time goes up exponentially with more (and paying) customers, and the difficulty in getting it right goes up exponentially with more runtimes, because you have a larger, more complex codebase. The thing is, *I know* you are going to get round to it - I'm psychic - but there is no way that I can tell an investor, a client, or a business partner that I'm psychic, they just aren't that enlightened - they go for the old-school way of making business decisions. Client - 'Can I run a report on this thing?', Me - 'Spirit guide says yes - soon.', Client - 'Shut-up fool. Bob says we should be on Amazon.' It wouldn't take much to stop that conversation from happening. </white-hat> <yellow-hat><red-hat> I don't want to use another platform. BigTable is, frankly, awesome. Its a killer feature. After using it, I don't want to contemplate the thought of managing my own data layer again. But I have to, because asynchronous processing isn't even on the map. :( </red-hat></yellow-hat> <green-hat> Perhaps - to get asynchronous processing up the issue list you could combine the following two issues http://code.google.com/p/googleappengine/issues/detail?id=6 http://code.google.com/p/googleappengine/issues/detail?id=109 and just call it 'Asynchronous Processing' - at least it would get above adding perl as a supported laguage. God forbid we couldn't deploy a perl application to app engine. </green-hat> I haven't got a blue hat, because someone lost it. I'm sure this kind of post is why you don't publish roadmaps :) Better tack this on as well - I'd love for you to secure the python interpreter - http://code.google.com/p/googleappengine/issues/detail?id=671 The actual code for doing so has been submitted with this issue, and its something you would want to do sooner rather than later so you don't break too many existing apps that rely on it being insecure. It looks like something you might be able to knock out fairly quickly? On Nov 5, 5:05 pm, Aral Balkan <[EMAIL PROTECTED]> wrote: > To illustrate my point further with an analogy: > > Google App Engine is here right now:http://icanhaz.com/rightscaleweb > > It needs to be here:http://icanhaz.com/rightscalepremium > > Aral > > On Nov 5, 3:54 pm, Aral Balkan <[EMAIL PROTECTED]> wrote:> The roadmap is a > great step forward, thank you. > > > I am, however, disappointed at seeing "Support for a new runtime > > language" on the roadmap for the immediate feature. > > > Quite bluntly, I would have expected better triage. > > <snip> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
