I definitely, absolutely love the idea of having appengine internally route
foo.com/api to api.foo.appspot.com. An under-the-covers targeting of
different apps/versions is the only way I can think of to get ssl for the
whole app without having to deal with how browsers handle the
*.appspot.com certificate. Plus, being able to configure different
instance configs with high or low latency would take advantage of smart
clients that actually know which requests _should_ take a certain amount of
time {before pre-warming requests, I had every gwt rpc log it's average run
time in a format I compiled in to set a "you should be done by now" timer
at 2x expected latency, so I could kill to old request and fire off a retry
without waiting 10 seconds for the request to die}.
Anyway, the extra perks of shared memcache would be nice, but I would be
more than absolutely happy to use it with nothing more than a single shared
datastore namespace to serve as inter-app-swap space. Being able to remote
api data over _would_ work, but paying for http + instance hours when all
we need is entity get() -> entity put() makes it far less than desirable.
I think, for standard users, they would have to pay flat billing for all
app versions as if they were the same app. Premium accounts already pay
$500/month and can just hook up multiple apps however they please, and just
pay for usage.
Please keep us updated, I'm very excited about the potential to wire up
multiple apps, especially if I can send requests to sub-apps / sub-versions
under a single ssl-friendly subdomain. =}
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/s4ZqgSpVPRoJ.
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.
