The threading issue is a really good point about why a native PHP runtime
won't work on App Engine. If you read the PHP discussion, you'll see why PHP
developers do not want to use Quercus - perhaps you can convince them
otherwise?
One last note: there is no more distinction between "App Engine" a
Partly true, partly not. Usage of ORM in PHP not common as in Java, but most
of the PHP based system has a an abstraction layer upon the database, and if
you change it, you can use your existing system on GAE. For example you can
run Wordpress on AppEngine with Quercus with a relatively small pa
My only experience with Mono is playing with Unity3D. What i gather from my
labs is a big backlog of libraries to be ported from .NET FW.
Most noticeable the Enterprise library (that you would obviously look for to
reduce engineering efforts and provide SLAs). I would compare them as CentOS
is to R
IMNSHO, the issue with a JS runtime for GAE is not the language but having a
purely async API to all of GAE's services. Node.js wouldn't work unless you
can fire off hundreds of async requests and get callbacks... but right now,
at least at the level of the documented API, you can only fire off 10
Thanks Jay! We really need to hear more from developers like you.
I won't repeat my comments re: PHP runtime, but if some developers would
show that they were serious about maintaining a JS runtime, we would do what
we can on our side to help out short of actually maintaining it. We'll try
to keep
Sadly, AppEngineJS is a ghost these days. It seems to have died around
December and is a few releases back. It is also based on a
no-longer-supported webapp framework that was part of RingoJS (the CommonJS
framework that runs on Rhino).
That said, I'm still using Ringo/Rhino on GAE, and it's
Ah ha, thank you for explaining that, I was wondering why go needs to do that.
On Mon, Jun 20, 2011 at 12:18 AM, Ikai Lan (Google) wrote:
> One thing you'll see in the Go runtime, for instance, is this need to
> retrieve an App Engine Context. The reason you don't have to explicitly do
> this in,
FWIW I'm still a bit skeptical about node.js (cue the army of people riding
the hype cycle coming down on me - but please describe to me JavaScript's
memory model, for instance), but we *do* seem to have the right expertise
here to build that out. Before this sort of thing gets prioritized, however
On 18 June 2011 21:01, Peter Petrov wrote:
> Personally, I'd be much happier to see Node.js supported on GAE, than PHP.
+1. You don't have to worry about that tricky threading stuff, if you can
just develop against event loop.
--
with regards,
Maxim
--
You received this message because you
The last time I tried using mono to host a C#.Net app it was a bit rocky. I
don't recall all of the specific issues anymore, but in the end we just
bought some windows servers
On Jun 18, 2011 12:48 AM, "Ikai Lan (Google)" wrote:
> Yikes. Those are great points, David. Thank you for that respon
Personally, I'd be much happier to see Node.js supported on GAE, than PHP.
Being 100% asynchronous (reactor-type), it would be a great fit for the new
per-instance pricing (despite being single-threaded).
On Sat, Jun 18, 2011 at 7:47 AM, Ikai Lan (Google) wrote:
> Yikes. Those are great points, D
Yikes. Those are great points, David. Thank you for that response. You're
right; I didn't even think about the multithreading. This would make PHP
prohibitively expensive. We're aware of the issues this causes for Python
developers on 2.5, and that's why we've committed to getting multithreading
fo
So zend + right scale are playing with a PaaS already, and there's another
that i forgot the name (or at least trying to).
I worked 5 years on massive PHP systems (+10 mill users, with oracle behind)
as SA and from that i gather many things:
- Hardware consumed tend to be 1.5 times more than o
my feeling is, given limited resource, I rather they improve what they currently
support instead of adding yet another language runtime and hope the
php community will
rally around it.
there is still plenty of things to do on the GAE-python and GAE-java
side. go was
just added as a new stack.
goo
Heck-- A key/value store is probably a better fit for Drupal than an RDBMS.
On Fri, Jun 17, 2011 at 11:56 AM, Branko Vukelic wrote:
> On Fri, Jun 17, 2011 at 5:24 PM, Wilson MacGyver
> wrote:
> > I don't think supporting php is a game changer.
> >
> > I have a feeling a lot of people that ask ab
On Fri, Jun 17, 2011 at 5:24 PM, Wilson MacGyver wrote:
> I don't think supporting php is a game changer.
>
> I have a feeling a lot of people that ask about php, wants to slap in
> wordpress, drupal, etc
> , run it on google app engine and forget about it.
>
> which due to datastore is not going
I don't think supporting php is a game changer.
I have a feeling a lot of people that ask about php, wants to slap in
wordpress, drupal, etc
, run it on google app engine and forget about it.
which due to datastore is not going to happen out of the box.
On Fri, Jun 17, 2011 at 10:09 AM, Ikai Lan
I think a lot of people blindly ask for PHP support because they think it
would imply SQL (specifically MySQL) support and be compatible with existing
PHP applications. So even if GAE gets PHP support, I think most of the PHP
users would have a very bad experience due to the datastore.
--
You
I just read this. The other day I was looking at a Python vs PHP comparison,
and it turns out 5.3 has added a lot of the missing features that I used to
complain about all the time when I worked in PHP4/PHP5-land:
http://wiki.python.org/moin/PythonVsPhp
Not saying that I personally prefer PHP - I
[11:26:32] guys, you tell me when i can fire the
barrage of questions :D
[11:26:50] Chiguireitor: you make it sound so fun
[11:27:04] lol
[11:29:49] yes im ready !
[11:31:16] <+proppy_google> trying to get more people in :)
[11:31:21] hehehe
[11:31:26] wauw
[11:31:33] the google invasion
[11
20 matches
Mail list logo