Please don't add support for other languages.

[Jonathan Feinberg]

I have opined:

http://blog.wordle.net/2008/06/i-wish-i-could-remove-stars-from.html

[Aral]

I wholeheartedly agree.

Aral

On Jun 27, 8:53 pm, Jonathan Feinberg <e.e.c...@gmail.com> wrote:
> I have opined:
>
> http://blog.wordle.net/2008/06/i-wish-i-could-remove-stars-from.html

[iceanfire]

I agree (even though I use to be a PHP developer and never understood
python until google appengine came out).

[peterk]

Ruby on rails is a really nice environment though..

I've just finished porting my project from rails to python and webapp,
and it was a bit more work than I'd hoped.

Everyone has languages they're most familiar with. I think more
languages can't hurt, but I'd put other issues ahead of those (like
getting SSL in, and, simply, opening up the billing system so we can
start scaling indefinitely).

[g-man]

Yes, and as you will see by my self-description as a 'Rails Refugee',
I too enjoyed Rails for several years. I admit the 'natural language'
syntax of Ruby is pleasant, and I also hereby stipulate that there are
many excellent goodies provided by Rails which make web development a
rather painless experience.

Be that as it may, there are also many fine features in Python, and
it's a much more 'programmerly' language, proven by many years of
active use and improvement, albeit not a pure OO conception, but so
what? It just works!

The same could be said about Django, of course.

When you come right down to it, and I'm speaking as a hobbyist now,
Google has probably cornered the market on smart people, has proven
itself to be an indispensable tool for constant, everyday usage by the
entire world, and can bring any amount of resources to bear on solving
the relatively trivial problems posed by the App Engine deployment. In
other words, it just works!

The very fact that an amateur such as I can cobble together a
primitive app that 'just works' in a matter of a few weeks, using
quite a spartan API, release it 'into the jungle' of the wild Internet
with only minor hiccups, and have not a care in the world about
servers, backing up data, security, and so many other roadblocks that
were in my path with Rails proves the concept of what the Google App
Engine is trying to accomplish, namely to bring a state-of-the-art web
application infrastructure to a huge user base worldwide.

In fact, I can see a day in the not-too-distant-future when creating a
web app will be as easy for anyone to do as it is to create an email
account today.

So, yes, all things considered, learning Python and the datastore API
should be no obstacle at all for a professional programmer.
Furthermore, I bet DHH has been (quietly and secretly) hacking away
furiously for about two months now, and will soon release some kind of
framework for 'Appengine on Rails', so get on board, everyone!

[Jerome West]

By its nature this will always be a controversial issue (as the
confrontational first comment on the blog post shows). I think it's
important to bear in mind that the people who starred the "give us
more languages" issues are generally not the people who are currently
using App Engine.

It will be great when there are more languages available, and everyone
is happy. I come from the LAMP world myself, and initially starred the
PHP issue. But I've removed my star from it now. It seems obvious that
it's far more urgent for some of the fundamental limitations on the
system to be dealt with first.

Lack of support for files over 1Mb is a killer for me. My app is
completely useless until this limitation is lifted, so I'm putting a
lot of faith in Google by investing my time and energy in learning a
system that's entirely new to me. Likewise, until we are able to pay
for extra resources, our apps are little more than proofs-of-concept.

I wonder, do we really know that the App Engine team are prioritising
the language issues over everything else? We know they said they'll
work on the issues with higher numbers first, but I would be surprised
if they hadn't deliberately excluded these issues from that principle,
at least for now.

What I'd really like to see is a statement from the App Engine team
letting us know what they're working on. As a developer, I know how
annoying it can be having to constantly report back to needy users
when what you really want to be doing is coding, but it would be great
to know what their priorities are.

[javaDinosaur]

Yes there are many missing features in the current software stack that
should take priority over other languages.

SSL.

Event API to signal batch processing tasks similar to Amazon.

Mass Datastore change API, e.g. whole db truncate, delete an entity
group, delete a Kind.

Point in time Datastore recovery up to the versioning limit.

Mixed mode authentication in a single app e.g. Google and custom.

Web tier swipe, e.g. invoke a named script on all running instances.

Page hit log reports.

[Ross Ridge]

Jonathan Feinberg wrote:
> I have opined:
>
> http://blog.wordle.net/2008/06/i-wish-i-could-remove-stars-from.html

The addition of languages other than Python is, in the long term,
pretty much inevitable. They stated their intention to support other
languages pretty much on day one, and the "runtime" field in app.yaml
suggest that they had this intention long before anyone was able to
star a single issue.

Despite this, and despite all the stars in the issue tracker, I don't
think you need to worry about Google's priorities here. While adding
other languages might a very important goal for Google, they haven't
been treating as if it were a very urgent one. There's no indication
that they've been ingoring more pressing issues, like those that
affect the reliabity of the service.

While there might be a team of developers currently dedicated to
adding support for PHP or Java or some other language, I doubt that
simply throwing in more manpower to work on other issues will get them
fixed that much faster. Especially if those developers don't know
Python. Also, I suspect a fair number of App Engine's limitations and
problems are the result of that fact that it's dependent on a number
of Google's proprietary internal technologies. Technologies that an
entirely different set of developers is responsible for maintaining,
and who unfortunately have their own set of priorities.

Ross Ridge

[max7]

I am against php in general. I think it should not be supported in
general as it is bad, hacky, misleading language. (magic_quotes,
register globals, etc. I know PHP6 would not have it)

Java is different from all other languages in general and it is
important to have it to compete with MS .NET datacenter.

It is obvious the that issue #1 would be implemented. If you will read
issue comments carefully you may even notice time frame for java
support implementation. (4 month - 1 year)

--------------------------------

I agree that SSL support and paid account support are most important
features.

[WalterJJ]

I also agree, 100%, it's amazing how fast one can learn and begin the
use of python and how clean is the resultant code ...It has the best
of several worlds; pascal, java, PHP... any further effort could be
for adding python libraries support and python perfomance improvement
and not multilanguage resources dispersion

Best regards,
Walter

[Ale]

Exactly!

Alejo

[luismgz]

I wouldn't go as far as limiting GAE to only python (although I
wouldn't mind ;-),
but I would surely rule out those languages developed with a "kitchen-
sink" way.
PHP is the first that comes to mind. The problem with it is is that it
was born as a hack to get little web apps done,
but it's not a general purpose programming language, and it shows.
I would also rule out Java because... well, because it's Java!
I wouldn't mind seeing ruby implemented, because it has many
similarities with python and seems to hit the same spot.

[babylon]

Why don't you people just shut up and continue developing your apps.
If you love python use it. Don't ask others to join you. I love python
but I need to use another language. Even if there are hundred
languages supported by GAE it will never bring any problem to all of
you.

[bowman...@gmail.com]

Honestly guys, this whole thread is based on what developers think,
and the technical pros and cons to adding more languages and what the
technical costs would be. Key word in all of this is "technical".
Whether or not, and when, to add more language support to AppEngine
will be based on business choices. If AppEngine is Python only, how
much will cost compared to if it support multiple languages? That's
just the way it is.

[Andrew Badera]

I wish I could star that reply, babylon.

[Ale]

Don't get us wrong, we like GAE. That's why we care it should have
better Python support before diluting efforts on other languages and
frameworks.

Many of the major Python templating engines are not supported yet.
Major frameworks besides Django are not working (or even their
components.) SSL support is missing and not even stated if planned or
not. No scheduled jobs. Static files are quite limited on count and
sizes.

Those issues compose into bigger problems, for example Django normally
uses templates and other things on filesystem and it's easy to end up
consuming the file limit quota. (It's painful to make a Django
template DB loader due to its non-modular design, just have a look at
existing modifications out there, incredibly complicated.)

My/our feeling, GAE is 95% there for release but there's a large
amount of people making pressure (top starred issues) on features for
v2 before v1 is completed. If negative stars on tracker were possible
("black hole") I bet the top ranked issues list would look very
different.

Alejo

[Andrew Badera]

Diluting effort ... if you had any idea with the GAE team looked like, perhaps you could share with us, since as far as I know, as far as anyone knows, it's just a black hole. For all we know they could have the resources, and be scheduled to, deliver 22 languages tomorrow, including full Python support. Or maybe the staff consists of just the few Googlers we see answering questions, but somehow that seems ridiculous.

Rather than make lame arguments against enhancing GAE because it doesn't suit your particular purposes, why not spend some time researching the actual ongoings of the GAE team, rather than complaining pointlessly in a public forum?

--
--
--Andy Badera
http://higherefficiency.net
http://flipbitsnotburgers.blogspot.com/
http://andrew.badera.us/
http://changeroundup.com/
and...@badera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera

[luismgz]

Relax baby! Don't take it that seriously...

[Lee O]

Although i am not really here to debate which language GAE should or shouldn't support, i think it is rather asinine to _not_ think that supporting multiple languages will weaken development progress. Time spent developing GAE for PHP,et al, is not time spent adding new features to GAE. Simply put, there is no way around it. Now whether or not this is a huge deal i am not discussing, because im not getting drawn into a pissing contest. I am just making the point that no matter how big the dev team is, taking any manpower away from developing new features for GAE, is just that, and there is no way around the argument.

--
Lee Olayvar
http://www.leeolayvar.com

[CarstenN]

Ross Ridge wrote:
>The addition of languages other than Python is, in the long term,
>pretty much inevitable. They stated their intention to support other
>languages pretty much on day one, and the "runtime" field in app.yaml
>suggest that they had this intention long before anyone was able to
>star a single issue.

Stating that intention would even make sense without any concrete
plans to support other languages. Or in other words: saying "We'll be
Python only for now" would've been a terrible mistake - regardless of
what the actual plans are.

I really don't think support for other languages will happen anytime
soon. But what do I know...

[Andrew Badera]

With zero knowledge as to how the GAE team is structured, what resources are dedicated to it, and what the timeline looks like, it's pretty asinine to make any absolute statements, period. No way around the argument.

[bowman...@gmail.com]

On Jun 28, 12:32 pm, Ale <joeplat...@googlemail.com> wrote:
> Don't get us wrong, we like GAE. That's why we care it should have
> better Python support before diluting efforts on other languages and
> frameworks.
>
> Many of the major Python templating engines are not supported yet.

Not GAE's problem. It's not their responsibility to make those work
with bigtable, it's up to contributors to get it working.

> Major frameworks besides Django are not working (or even their
> components.)

Once again, not their problem.

> SSL support is missing and not even stated if planned or
> not.

That has nothing to do with Python or other language support.

> No scheduled jobs.

Once again, nothing to do with language support. And you can work
around that with your code. People have been working around not having
access to cron on shared web hosts for over a decade. You include a
global function that checks the time, and checks job status. If it's
past a certain and the job hasn't run, flag the job as run, then run
it.

> Static files are quite limited on count and
> sizes.

And they will be for other languages as well. Not a language specific
problem.

>
> Those issues compose into bigger problems, for example Django normally
> uses templates and other things on filesystem and it's easy to end up
> consuming the file limit quota. (It's painful to make a Django
> template DB loader due to its non-modular design, just have a look at
> existing modifications out there, incredibly complicated.)
>

Not a python specific problem.

> My/our feeling, GAE is 95% there for release but there's a large
> amount of people making pressure (top starred issues) on features for
> v2 before v1 is completed. If negative stars on tracker were possible
> ("black hole") I bet the top ranked issues list would look very
> different.
>
> Alejo
>
> On Jun 28, 4:51 pm, babylon <babylon2...@gmail.com> wrote:
>
>
>
> > Why don't you people just shut up and continue developing your apps.
> > If you love python use it. Don't ask others to join you. I love python
> > but I need to use another language. Even if there are hundred
> > languages supported by GAE it will never bring any problem to all of
> > you.
>
> > On Jun 28, 3:53 am, Jonathan Feinberg <e.e.c...@gmail.com> wrote:
>
> > > I have opined:
>

> > >    http://blog.wordle.net/2008/06/i-wish-i-could-remove-stars-from.html- Hide quoted text -
>
> - Show quoted text -

[Andrew Fong]

If you need an "AppEngine for Rails", check out Heroku.

[g-man]

Yes, Grasshopper, Heroku bring much enlightenment!

[babylon]

I don't think this issue should be discussed at all. It's not our job.
GAE development speed will always the same no matter what the plan is.
If there is more request, I believe Google will allocate more
engineers to work on it. So, no one should worry about this. Let
Google decide which is better for GAE.

[Brett Morgan]

On Sun, Jun 29, 2008 at 4:22 AM, Andrew Badera <and...@badera.us> wrote:

Diluting effort ... if you had any idea with the GAE team looked like, perhaps you could share with us, since as far as I know, as far as anyone knows, it's just a black hole. For all we know they could have the resources, and be scheduled to, deliver 22 languages tomorrow, including full Python support. Or maybe the staff consists of just the few Googlers we see answering questions, but somehow that seems ridiculous.

I know for a fact that the appengine team is a fair bit bigger than the few(?) people we see interacting on the mailing list. The reason i stick a question mark on the end of few is that i've seen at least one google engineer on this mailing list using his private email address. Don't think for a minute that the appengine team are ignoring the mailing list. Tom Stocky spoke at Google Dev Day Sydney (http://sites.google.com/site/developerdayaustralia/google-developer-day-2008-australia/building-scalable-web-applications---an-introduction-to-google-app-engine) and made it plain that the whole team are aware of what is happening in this forum.

On the subject of language support, my feelings are that adding a language is a fair chunk of work. Each language needs to be vetted for any security loop holes that would allow a malicious developer to get outside the language's sandbox. However, there is a lot of work that the appengine team have done that should be usable across all languages, either directly (the back end datastore and urlfetch infrastructure) or after a straight port (the python side datastore infrastructure).

The most important thing that people on this list can do to keep app engine alive is to build webapplications that show case what this platform is capable of. Sure, that means we are going to hit limits. The AppEngine team will help us to find ways around those limits. Together we can win, and win big. =)

--

Brett Morgan http://brett.morgan.googlepages.com/

[Lee O]

So you dont think that any time dedicated to something else (Say support for other languages) is less time spent on new GAE features? Are they using clones to program or something? They seem to be in two places at once doing two things at once, if i'm wrong.

[Andrew Badera]

You have no idea what resources are dedicated to what tasks. For all you, I or almost anyone knows, perhaps they've capped their Python resources, and the rest are dedicated to non-Python specific tasks, regardless of what issues we mere users create or star or argue about pointlessly.

None of us can say what effect new languages will or won't have, because we have absolutely zero insight into the structure of the GAE team, the structure of the resources, the structure of the intended timeline.

Feel free to show me where I'm missing something here, perhaps you have inside knowledge of the team or GAE program overall that the rest of us lack?

[Lee O]

Actually i do suppose that is a possibility, if they have so many developers working on it that it is _impossible_ to fit anymore in to the dev team for GAE features, then i can actually agree with your statement. But barring the theory that there are too many devs to fit in the room, then my argument stands.

I'm not saying there shouldn't be other languages, im just arguing a stupid little point. The point that if you take 5 devs from Feature X and put them into Feature Y, then Feature X has 5 less devs. I mean.. mathmatics and all. Now you might want to fight for the reverse argument of if you "give" Feature Y 5 new devs, then Feature X isn't missing any! Again, this doesn't quite hold water, because thats still 5 devs _not_ on Feature X. If Johnny has 5 apples, and Billy has 20 Apples, well Johnny has 5 apples that Billy does not have.

But i do agree that it is possible to have too many to fit in the room. So if you are right, and Billy did have 5,000 apples in his bedroom, and thus, he could not fit anymore in, well then Johnny can have his 5 apples without actually taking "apples" from Billy.

Do tell though, i am curious about your perspective on the matter.

[Andrew Badera]

GAE sits on top of existing Google architecture.

I'm going to guess the actual GAE team, working to expose the underlying platform to us, and support us, probably consists of 20-100 team members at this point; maybe 200-250, but if I was putting money on it, the number's under 200.

That's all the speculation I have to give you at this point. How many people are devoted to what sort of purpose is impossible to say. Your room-stuffing metaphor doesn't play -- for all we know Google has that room divided into five or ten sections to begin with. Or maybe it is all one team, all working on the same backlog. But I doubt it. I'd bet it's at least a couple different teams, each with their own dedicated backlog, with minimal interdependence between different teams' tasks.

What we request, or what we bitch and moan about, will only influence the relevant team's backlog, it won't move team members from one team to another. I suppose it could affect future hiring or new resources though.

[Lee O]

Actually the room stuffing metaphor was yours not mine ;P. Your the one who mentioned that they might have "capped their Python resources". Capped, Reached Maximum Capacity, Stuffed Room.. etc. I apologize if a room at its maximum capacity was not close enough of a comparison to resources that have reached their limit.. :p

[Andrew Badera]

No, capped, as in put a cap on how many resources they've chosen to dedicate out of the available pool.

Speakie the techie? Speakie the businessy?

In no translation or interpretation does capped == a full room or any mangled metaphor along such lines, except in the mind of someone who can't let go the losing side of a pointless argument ;)

[Lee O]

Well ofcourse i ment maximum resources as google intended. I doubt google is assigning the "Maximum Possible Developers" to GAE. They arent going for some world record my friend. But hey, if you wanna try and change the meaning to suit your needs go ahead ;P

 

I'm actually surprised though that you are still fighting the idea that Billy having 5 apples means Johnny has 5 less apples.

 

So, if Billy has 5 Apples, and Johnny has 20 apples, do you see that Billy has 5 apples Johnny doesn't? I mean lets break it down as simple as we can to stop beating around the bush. :p

[Andrew Badera]

Sorry, friend, but you're comparing apples to oranges here.

[Lee O]

True enough.

 

If Feature Y (Billy) has 5 Developers (5 Apples) assigned to it, than that is 5 Developers (5 Apples) that Feature X (Johnny) does not have. Is that not true? Or is it somehow still apples and oranges, because i'd love to discuss it. Though i suppose if you have avoided the repeated question thus far you wont bother. Blech, works for me.

[babylon]

But, I believe Google more than able to buy another five apples.

> >>>>>>>>>>> On Sat, Jun 28, 2008 at 12:32 PM, Ale <joeplat...@googlemail.com>

> ...
>
> read more »

[Michael R. Bernstein]

On Jun 29, 5:54 am, "Lee O" <lee...@gmail.com> wrote:
>
> I'm not saying there shouldn't be other languages, im just arguing a stupid
> little point. The point that if you take 5 devs from Feature X and put them
> into Feature Y, then Feature X has 5 less devs. I mean.. mathmatics and all.

Buried in your point are two assumptions:

1) that software developers are interchangeable resources that can be
shuffled around by management fiat.

2) that adding more developers to a 'feature' will get it done
faster.

Both are false.

- Michael

[Andrew Badera]

Thank you.

[Lee O]

Note that although i am replying, i do like your argument. Well thoughtout :)

1) Well software developers are, interchangeable are they not? Sure Frank McCoder may not be able to program in python, but if you spend money on Frank McCoder than you are taking a development slot (an apple) and using it for Feature Y. I'm not saying that Frank McCoder can be tossed around like an apple, but rather that the generic "Developer" can. In this case, if we want to fully be abstract, a developer in this example is nothing but what he really is, resources spent (money) to get a job done (Feature Y).

So if you have enough money for 25 apples, and you put 5 apples worth in Feature X, then Feature Y is missing 5 "potential" developers. The resources are there to give apples to Feature Y, but it is not getting them, because they are on Feature X.

2) I don't believe i said anything about speed, but perhaps i did. Either way if i did, you are right. Faster may not be true, but generally, a project will always be worth X Dollars, which costs because Y ManHours are spent on it. Yes a bug can develop at anytime, etcetc, but were not pondering the universe of possibilities (or atleast, i'm not heh).

[babylon]

Whatever it is? It is not your job to talk about it. You must know
Google will never listen to you as they already said they will support
another language and nothing you can do about it. So, accept it.

[Filip]

Actually, I believe that they have said in the GAE Fireside Chat at
Google I/O that they ARE working on additional languages, and that it
DOES take priority over other concerns like SSL.

Which to me is crazy (and I didn't do Python before GAE).

F.


On Jun 28, 11:17 am, Ross Ridge <rri...@csclub.uwaterloo.ca> wrote:

> Jonathan Feinberg wrote:
> > I have opined:
>
> >    http://blog.wordle.net/2008/06/i-wish-i-could-remove-stars-from.html
>

> The addition of languages other than Python is, in the long term,
> pretty much inevitable.  They stated their intention to support other
> languages pretty much on day one, and the "runtime" field in app.yaml
> suggest that they had this intention long before anyone was able to
> star a single issue.
>

> Despite this, and despite all the stars in the issue tracker, I don't
> think you need to worry about Google's priorities here.  While adding
> other languages might a very important goal for Google, they haven't
> been treating as if it were a very urgent one.  There's no indication
> that they've been ingoring more pressing issues, like those that
> affect the reliabity of the service.
>
> While there might be a team of developers currently dedicated to
> adding support for PHP or Java or some other language, I doubt that
> simply throwing in more manpower to work on other issues will get them
> fixed that much faster.  Especially if those developers don't know
> Python.  Also, I suspect a fair number of App Engine's limitations and
> problems are the result of that fact that it's dependent on a number
> of Google's proprietary internal technologies.  Technologies that an
> entirely different set of developers is responsible for maintaining,
> and who unfortunately have their own set of priorities.
>
>                           Ross Ridge

[Filip]

Actually, they were pretty forward about these issues at Google I/O.
The team structure, size, resources and priorities were discussed.
Unless their approach has changed since, they are effectively slowing
solving other issues (like SSL) on order to add support for more
languages.

> --Andy Baderahttp://higherefficiency.nethttp://flipbitsnotburgers.blogspot.com/http://andrew.badera.us/http://changeroundup.com/

[Filip]

I believe you are dramatically overestimating the size of the number
of people working on exposing the GAE team. At Google I/O, they
discussed their team was not near that 20 number.

> >>>>>> On Sat, Jun 28, 2008 at 12:32 PM, Ale <joeplat...@googlemail.com>

[LH]

I think it's a mistake to add new languages before older issues are
fixed.

Most posters for "add php", "add perl" didn't get the point that 90%
of the time you work with basic language structures or google apis.
I learned the basisc of python for web development in 1 day, and the
google api basics in another day. I know a lot of other languages, and
it's not a big difference in the basics, and google apis are new for
all.

So whats the point in supporting php, perl and co? Most users will
save one day or two, but is that the big point?

The biggest mistake is that many think that they can use there old
software on google app engine, and get cheap webspace. But the fast
is: There won't be a port of phpbb, postnuke and co. for app engine in
the next years, they are not written for such a plattform.

Hate me for that, but I think that every software developer who isn't
able to learn python on app engine isn't a very good software
developer. Understanding new languages and there environment is a
basic task for every developer.
Developers who are fix on one language are often use the a tool even
when it's not the best one for a task.

[Filip]

Actually, I don't believe the question is whether they should or
should not add more languages. They have said they will, so there is
no way back from that road. They didn't share dates, but on the
fireside I got the impression it is as important the ability to bill.
Which makes adding languages a short term objective of the GAE team.

I have to say, there is something to be said for adding languages. I
have learned Python for GAE, coming from C# before. That really was
not hard to do. I believe Python is easily learned, gets you going
quickly, and I've discovered a lot of power once you dig deeper since.
I would not likely switch languages to say Perl or Java if the ability
was added. But that is hardly the point. The importance of adding more
languages is that GAE proves in code that it is an open development
platform. It proves they are not trying to lock in people (there is
more to the lock-in story, but that's for a different discussion. I
believe the GAE team has their intentions in the right place).

However, the point of your discussion is that you want to anti-star
languages BECAUSE that would free up resources for other things. This
is where we agree.

I can see where the GAE project comes from. Initially a proof-of-
concept evolving into a real project and getting released early to get
feedback, here we are with an amazing product that still has a lot of
rough edges to work on. But that is the past. In the near future, a
new OS war is bursting to the foreground. Central to Yang's plans for
Yahoo's comeback appears to open their infrastructure to external
developers. Microsoft is working hard on a .NET platform that runs on
their own servers and is backed by the already functioning but also
still early SSDS (and integrates with their line-of-business apps,
which is a serious short-term threat to Google as a platform). Amazon
is working on improving the federation of machines and power of the
database so that you can deploy and forget with scale on their
platform too. Salesforce.com has been wooing business customers for
some time now, but needs to come down from their ivory marketing tower
and show the average developer they are a platform for all orgs too.
In short, welcome back to the OS wars of the 80's. This is an
important war, because as a platform the Web is far superior than the
PC (in terms of user friendlyness and zero worries for the user).

So I'd say GAE should get more prominance with Google. The early
phases are behind us, and it is time to ramp up the team so that
existing work can continue as planned but other work planned for mid-
term can be implemented in the short term.

If you agree, I know if a good way to tell the GAE team you agree:
star issue 535, perhaps a rather unusual issue report...
http://code.google.com/p/googleappengine/issues/detail?id=535

Filip.

[David Symonds]

On Mon, Jun 30, 2008 at 5:33 PM, Filip <filip.v...@gmail.com> wrote:

> Actually, they were pretty forward about these issues at Google I/O.
> The team structure, size, resources and priorities were discussed.
> Unless their approach has changed since, they are effectively slowing
> solving other issues (like SSL) on order to add support for more
> languages.

Incidentally, the biggest problem with SSL is that it does not scale
well, at least in the incarnation that comes with a lot of common web
browsers. The hard thing for the GAE team is not just getting around
to things, but doing them right such that they will scale. As various
folk have noticed, one difficulty is hardening/sandboxing languages,
but almost a completely orthogonal difficulty is providing
language-independent features that will scale well, such as the email
API.

Dave.

[dsw]

The Google App Engine team has finite resources and asking them to
support more languages takes away from their overall effort.

Plus, this forum exists for people to express what they thing, which
the GAE team finds valuable. Telling people to "shut up" is exactly
not the point of the forum. If you think that's what people should
do, perhaps you should lead by example.

[dsw]

It is very bizarre of you to be telling people that they should not be
discussing an issue at all on a forum set up explicitly to discuss
issues.

[Lee O]

Huh?

Ok i'll be honest, i have no idea what your talking about here.

1.) What do you mean by "Whatever it is?"?

2.) Umm, i never said it was my job to talk about anything.. but because i am not employed to talk about something, that does not mean im not going to do it. Odd argument imo, specially considering _I am not talking about what google should or shouldn't do_! I was specifically replying to someones statement, and we were discussing it. So even if Google did "listen to me" they would not actually do anything, because never, did i once, say that google should or shouldn't support more or less, though i do believe my vote was for "more python".

I'm honestly hoping your replying to someone else, but accidentally replied to me.. its a rather confusing bit of backlash you gave me .. heh.

[Lee O]

Seems someone agrees with me (bout damn time!) haha.

But yes, as my whole argument was, i too agree that putting resources in one field of development can do nothing but take away from other fields of development. I'm not casting my opinion on where they should develop, i am just fighting the idea that supporting more languages, with finite resources for development, could not possibly affect other fields of development. I honestly find it asinine.

[Andrew Badera]

Got huge ego?

You  toss around the term asinine like only an asshat could.

You've obviously never developed a system of any significance. What respect I might have had for you is toast.

Without having any idea what the intended release plan is, what the product owner or analog's priorities are, or what resources are dedicated to which tasks or stories, your statements are not only that of a blowhard, but a retarded blowhard at that.

[Brett Morgan]

Guys, can we at least keep things civil? I know I'm one to talk, what with my frequently impolite ways, but calling each other asinine and asshats is probably a step too far.

Can we agree that google will do with it's time what it thinks is best? They are a company, and will follow the business imperative. Multiple languages are a stated business requirement for the platform, but it is a large project in and of itself.

Yes, background processing and ssl are also known requirements for commercial usage of the platform. Background processing requires engineering time to think out the appropriate way to allocate resources fairly and in a way that isn't as hard to grapple with as the sql -> gql transition. SSL requires some interesting fancy footwork from the infrastructure guys.

Can we get on with discussing things that are within our control, i.e. applications we are coding on the platform?

--

Brett Morgan http://brett.morgan.googlepages.com/

[babylon]

Anyway he can become a good human resource manager...Hire him. Quick
or you will miss a chance to increase your profit.

[Lee O]

Heh, sorry you feel that way. Though i have yet to here arguments against my simple, i mean very simple, examples. Beat around the bush all you want, i dont mind being wrong, but i just never saw you explain against my examples. Not that i really expected you to.

I assume Daniel is just as wrong as i am in this case? I mean if hes not, please do explain the differences in our cases (all that apple/feature/developer jazz).

Anyway Brett is right. This is getting a bit personal and i can clearly see neither of us can come to an understanding.. which is a shame, honestly. I love debating, but i dont feel my debate was acknowledged at all by you.
Though, i did like Michaels comments. I believe they made a good counter, but slightly more realistic than my theoretical examples (since nothing, especially programming, can be fully predicted).

Anyway, yea..

/asshat

[Lee O]

*hear, and *all other grammar/spelling mistakes*

[Lee O]

On Mon, Jun 30, 2008 at 6:31 PM, Brett Morgan <brett....@gmail.com> wrote:

Can we agree that google will do with it's time what it thinks is best?

Nothing aginst you ofcourse, i just wanted to make it clear that my discussion was never for/against what google should or is going to do. Just simply the whole idea of where resources are put, affect other resources.

I feel a resource used for Feature Y, will affect Feature X in one way or another (apples, etcetc). Andrew obviously doesn't.

[Filip]

> Can we get on with discussing things that are within our control, i.e.
> applications we are coding on the platform?

I guess the only reason we are discussing this here, is because some
of use feel unsatisfied with the star system. That's because the star
system seems to be flooded by people who are not using GAE, and making
requests simply to have a free host, and some of us feel that more
important issues get stalled.

I know it is simply too early to be frustrated. Google has released
early and is releasing frequently, so it is just a matter of time
before all of our needs are met. At the same time, this platform is so
close, with just a few features missing, that it is really hard not to
use it.

Perhaps because we are dead set on creating commercial applications on
a (for now) non-commercial system. But you have to admit, if billing
CPU hours is at the absolute number 1 on Google's to-do list, then it
is fair to assume that non-commercial use is not their primary target,
but just a test bed.

Now, I know for a fact that the GAE team are smart cookies. They don't
need us to tell them their priorities. But feedback never hurts.

More importantly, some of the discussion has been about whether the
resources are finite. Off course, the team is a very finite resource,
and the only way to get anything done is to set priorities. That's a
fact of life on any project in any large organisation.

But it is also true that teams can grow. Usually, budget increases
need to be justified, and higher management must approve after serious
debate on the importance. I believe GAE is very important, and I
believe this discussion has shown that many people feel strongly about
the ability to use GAE as a commercial platform, whereas others feel
strongly about supporting more languages. So I'd say this discussion
has been worth the digital ink and apparent emotions (though I don't
see the point of blocking the discussion or name calling).

I hope we have helped the GAE team by providing them the arguments to
enlarge the team, and have some people work in parallel.

Filip

[Lee O]

Although i may not agree on every point, i do agree that GAE is very close to becoming something huge.. and its only in preview. This will get very big, assuming Google keeps it all up :)

[Michael (blog.crisatunity.com)]

On Tue, Jul 1, 2008 at 3:24 AM, Filip <filip.v...@gmail.com> wrote:

That's because the star
system seems to be flooded by people who are not using GAE, and making
requests simply to have a free host, and some of us feel that more
important issues get stalled.

I think if GAE is perceived as essentially free web hosting resources and nothing larger in scope, that is squarely Google's fault.  Heck, I understand what the larger issue they are pursuing is, and I only see the GAE trial to date as nothing much more than free web hosting.  So, why wouldn't the masses in the main who don't care about the larger issue see GAE as anything much else?

[Andrew Badera]

Straw man? Check. False dichotomy? Check. I'm done with your obvious inability to discourse intelligently Lee.

[Jonathan Feinberg]

On Jul 1, 11:33 am, "Andrew Badera" <and...@badera.us> wrote:
> Straw man? Check. False dichotomy? Check. I'm done with your obvious
> inability to discourse intelligently Lee.

He's the Stephen Colbert of programming... except he's not kidding!

[Michael (blog.crisatunity.com)]

On Tue, Jul 1, 2008 at 4:34 PM, Jonathan Feinberg <e.e....@gmail.com> wrote:

He's the Stephen Colbert of programming... except he's not kidding!

I'm clapping with two-fingers that's such an elementary school cool kind of observation.
 

[Brett Morgan]

So what would you have done differently, as google, so as to position this as something other than free hosting?

[Brett Morgan]

As much as I find all the insults amusing, and I do, but can we call it quits? Seriously...

[Lee O]

Nice! :p

Seriously though, i do hate debates going no where and i would love to discuss this off this forum/thread, but as it is now your now ignoring my questions so i doubt we can go anywhere. But i am not kidding, please drop me a line, i would _love_ to get this worked out.. and that is, come to an understanding over this silly debate.

[Lee O]

Or hell, i'll email you (no reason to try and have you make the first move). Hopefully out of this forum we can actually discuss this.

*this argument is done on this thread, sorry for the outage*

[Michael (blog.crisatunity.com)]

* Mention the competiton - don't just assume because I am the supercool Google everyone will just "get it"
* Explain even once, somewhere, anywhere, in some meaningful way what GAE is *not*
* Deliver on the premise of no "infrastructure headaches" scaling by providing more means other than begging and hoping in this informal forum when big issues with something like, say indexes going awry, cripple deployed applications (now this forum is very responsive, mind you, but not worthy of an entire forward-thinking development and deployment "platform")
* Publish a plan, be accountable to a direction, something more than here's some stuff to play with and "we'll let you know" on the rest

I could probably come up with more, but I think you get my point.  Right now GAE is a toy.  First and foremost, without a clear cut means to understand how using the Big Table isn't a lock-in path - how can anyone consider GAE more than a hobbyist plaything?

[Filip]

> I could probably come up with more, but I think you get my point.  Right now
> GAE is a toy.  First and foremost, without a clear cut means to understand
> how using the Big Table isn't a lock-in path - how can anyone consider GAE
> more than a hobbyist plaything?

You are right about these remarks. GAE will need to communicate
differently with business users than it has done with consumers. You
are also right that GAE currently has a lot of gotcha's when you start
using it as a commercial platform. We'll need to talk a lot with the
GAE team to move ahead, and they have a lot to learn (and staff to add
to meet these new demands). It seems that they first want to get the
platform to the next stage before doing this. That's fair, and part of
the release-early strategy. I'm pretty sure that when Google finally
walks to and talks to major businesses they want to be pretty sure the
platform is ready for it. Consider yourself a beta tester, or someone
waiting on the sidelines. Either option is fair, and has its own
tradeoffs.

At the same time, GAE is one of about 4 or 5 major Internet platforms
that will dominate the software industry for the next decade, and
arguably it is the most advanced one at this point in time. That may
change in the future, but there is no lock in. It is perfectly
possible to run the same Python code without changes on at least two
(Amazon & Microsoft) and likely three (Yahoo!) competing platforms,
and the libraries GAE provides are easy to port to those platforms
(providing bindings to the native databases, email systems,
etceteras).

My take is that I develop for the GAE platform today, get a small set
of paying customers early, learn the new business, explore new
business models, and rapidly build the abilities of the application on
actual revenue and customer demand. These are things you can do today
with GAE. Sure, the process is not ideal, but you can do it. Of you
can wait until more mature platforms offer better tools and save you a
lot of time and angst. That is a good position too.

Filip.

[DennisP]

Gmail has SSL so apparently it's a problem that Google is capable of
solving. But I wouldn't be surprised if it doesn't happen until the
paid version is released.

[Andrew Badera]

SSL is an easily solved problem. SSL accelerators are cheap, easy to manage add-on, plug-in pieces of hardware. But yeah, why offer it for free if you're planning to offer a paid service?

[Mike Orr]

If you look at the "Accepted" tickets, none of them are for new
languages. I assume "Accepted" means the dev team plans to work on
them. The ones that are accepted either have to do with things that
make it difficult to run frameworks or template engines on App Engine,
and downright bugs that need to be fixed anyway.

Google *has* announced that they're planning to offer other languages,
stars or no starts. That doesn't necessarily mean they're giving the
language issues 4000 times more attention than the other issues just
because they're starred so much. Porting a language is difficult and
I expect it will take a long time, especially since you also have to
create a runtime environment, a dev emulator, and some kind of minimal
framework. Most of these other issues are short and quick in
comparision. And any other language will have the same kind of
toddler period and bugs that Python is having on GAE; it won't just
hit the ground running.

Regarding SSL, obviously without it e-commerce will never migrate to
App Engine. And e-commerce providers have the biggest wallets. So
presumably SSL will be offered at the same time paid services are, or
shortly thereafter. Unless Google doesn't care that much whether App
Engine succeeds. Since Google is not the sort of company to charge
$30,000 for its lowest-level services, I expect there will be a
low-cost SSL option for basic/hobbyist apps, and higher-cost options
for storefront apps. They may even offer "business packages" with SSL
bundled with other services.

--
Mike Orr <slugg...@gmail.com>

[David Symonds]

On Sat, Jul 5, 2008 at 9:00 AM, Andrew Badera <and...@badera.us> wrote:

> SSL is an easily solved problem. SSL accelerators are cheap, easy to manage
> add-on, plug-in pieces of hardware. But yeah, why offer it for free if
> you're planning to offer a paid service?

It's not as easy as you might think, and it's not because of the
computational overhead of doing the encryption, etc. It's because the
current widespread SSL version (SSL 3, a.k.a. TLS 1) requires the
hostname in the certificate to match one particular IP address, so
multiple applications per IP address or applications across multiple
IPs don't work all that well. TLS 1.1 solves that, but it's still not
as widespread as it will need to be.

Dave.

[Andrew Badera]

I'd assume that SSL would be specific to the domain being served, and the price charged would be in line with the costs of per-domain SSL. If it were offered for free, I'd bet it's going to be in a specific domain you have to pass into and back out of as part of your transaction.

F5, for instance, offers a solution for cloud SSL. The problem's been solved over and over again. Not difficult.

--Andy