[google-appengine] Re: Feature Request: Serve content from default google storage bucket without cross origin javascript

['George (Cloud Platform Support)' via Google App Engine]

Hello Darian, 

How would you like to serve files from storage, exactly? Who would be the 
recipient, in that case? 

You may consider opening a feature request in the issue tracker 
, where developers would evaluate it and 
decide upon its implementation. More detail is needed, than provided above, 
and a well-formulated and complete use case helps a lot in getting the 
feature request processed quickly and efficiently. 

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-appengine+unsubscr...@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-appengine/ef17c88e-31ec-496c-a9a6-6edc60c80b34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: [Feature Request] Friendlier Error Pages

[Simon Knott]

Doesn't this functionality already exist?

https://developers.google.com/appengine/docs/java/config/appconfig#Custom_Error_Responses
 
https://developers.google.com/appengine/docs/python/config/appconfig#Custom_Error_Responses
 

Cheers,
Simon

On Tuesday, 18 September 2012 14:47:36 UTC+1, hyperflame wrote:

 Would it be possible for GAE to display user-friendly error pages to 
 users? 

 Right now, if a hosted app fails to execute (for whatever reason) GAE 
 sends out a HTTP 500 error. This error page consists of the following 
 words: Server Error: The server encountered an error and could not 
 complete your request. If the problem persists, please report (http:// 
 code.google.com/appengine/community.html) your problem and mention 
 this error message and the query that caused it. 

 While developers understand that message, it is not user-friendly, and 
 doesn't report the correct action for the user to take. If my 
 organization's app fails, I want the user to report the failure 
 directly to my organization, not to a general Google mailing list. 

 What I'd like to see is a more user-friendly error page; perhaps you 
 could write something along the lines of We're sorry, but your 
 request has encountered a problem. Please email us (email address 
 here) to let us know. And then put the app owner's email address (or 
 Twitter/Facebook/etc account name) as a clickable link. 

 Or you could allow us to specify a static page to serve up whenever a 
 failure occurs. Amazon S3 does something similar, where you can 
 specify a static page for 404 errors. Or even just allow us to put in 
 a redirect url; if a 500 error occurs, GAE could reply with a Moved 
 Temporarily code and redirect to the redirect url. 

 While we all hope and aim to build web sites with no downtime, errors 
 do happen occasionally, and this would be a huge help in the UI/UX 
 department. 

 Thanks for your time. 



-- 
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/-/ZrTFnv2yXPwJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Feature Request I Think....

[Chris Ramsdale]

For the use case you provided, why not split the low latency and high
latency requests into two different apps (each with specific performance
tuning)?

-- Chris

On Wed, Dec 21, 2011 at 12:10 PM, stevep prosse...@gmail.com wrote:

 Still voting for task queue optimization. Hopefully we get TQ access
 in the /api app. Example, if I get a huge burst of traffic, for
 certain types of recs I would much rather build a queue backlog rather
 than spin up new 10s latency instances. TQFTW. stevep.

 On Nov 29, 11:36 am, Chris Ramsdale cramsd...@google.com wrote:
  Great feedback. Here's the model that I've been envisioning:
 
  - I have foo.com and foo.com/api
  - foo.com serves up my UI and needs to be super-fast
  - foo.com/api serves up non-realtime API requests
  - both route to a separate App Engine app
  - foo.com has max pending latency of 200ms, and several idle instances
  - foo.com/api has a max pending latency of 10s
  - Each app is part of a larger system that is configurable within the
  Admin Console
  - Being part of a larger system sets up the correct ACLs between apps
 and
  services (e.g. each app is able talk to the same Datastore)
 
  A couple of notes:
  - There needs to be a simple way of routing requests. Routing foo.com to
  the system, and configuring paths that map to apps (e.g. /api routes to
  api.foo.appspot.com under the covers is one suggestion)
  - Configurable Memcache that can be shared by each app would be nice,
 still
  iterating on this one
  - Expose a few more Backend properties to Frontends, and one could
 imagine
  Backends and Frontends merging under this model
  - Is there system billing and per-app billing?
 
  -- Chris
 
  On Fri, Nov 25, 2011 at 7:26 AM, Jamie Nelson jamie.nel...@promevo.com
 wrote:
 
 
 
 
 
 
 
   How about a header we can append to have a request routed to a
   particular instance-class?
 
   For those of us using gwt, appending an @Instance(target=a1) or
   @Latency(expected=2500) annotation to rpc methods could append the
   appropriate header to route requests based on their expected latency.
 
   This would be faster for all of us, and easier on your servers.
 
   If this feature is released, I will personally write the generator
   patch to implement the annotation {as opposed to have RpcAsync methods
   return RequestBuilder to manually set each request}.
 
   On Nov 25, 7:01 am, Joshua Smith joshuaesm...@charter.net wrote:
On Nov 24, 2011, at 12:06 PM, stevep wrote:
 
 Seeing the
 many new names from Google in the forums, I'm assuming that is the
 case.
 
I noticed this, too. Can anyone from google comment (just between us
   girls), is GAE getting some traction inside the googleplex now that
 you're
   out of preview? Do you get mentioned in high-level meetings? Are you
   getting some more budget to work with? Are new insanely smart people
   looking to get into your group? Is Brandon's mermaid costume discussed
 at
   every water cooler?
 
-Joshua
 
   --
   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
   google-appengine+unsubscr...@googlegroups.com.
   For more options, visit this group at
  http://groups.google.com/group/google-appengine?hl=en.

 --
 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
 google-appengine+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.



-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: Feature Request I Think....

[Brandon Wirtz]

You'd either have to put a proxy infront or serve off two urls, not an ideal
use case.

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Chris Ramsdale
Sent: Friday, December 30, 2011 12:58 PM
To: google-appengine@googlegroups.com
Subject: Re: [google-appengine] Re: Feature Request I Think

 

For the use case you provided, why not split the low latency and high
latency requests into two different apps (each with specific performance
tuning)?

 

-- Chris

On Wed, Dec 21, 2011 at 12:10 PM, stevep prosse...@gmail.com wrote:

Still voting for task queue optimization. Hopefully we get TQ access
in the /api app. Example, if I get a huge burst of traffic, for
certain types of recs I would much rather build a queue backlog rather
than spin up new 10s latency instances. TQFTW. stevep.


On Nov 29, 11:36 am, Chris Ramsdale cramsd...@google.com wrote:
 Great feedback. Here's the model that I've been envisioning:

 - I have foo.com and foo.com/api
 - foo.com serves up my UI and needs to be super-fast
 - foo.com/api serves up non-realtime API requests
 - both route to a separate App Engine app
 - foo.com has max pending latency of 200ms, and several idle instances
 - foo.com/api has a max pending latency of 10s
 - Each app is part of a larger system that is configurable within the
 Admin Console
 - Being part of a larger system sets up the correct ACLs between apps
and
 services (e.g. each app is able talk to the same Datastore)

 A couple of notes:
 - There needs to be a simple way of routing requests. Routing foo.com to
 the system, and configuring paths that map to apps (e.g. /api routes to
 api.foo.appspot.com under the covers is one suggestion)
 - Configurable Memcache that can be shared by each app would be nice,
still
 iterating on this one
 - Expose a few more Backend properties to Frontends, and one could imagine
 Backends and Frontends merging under this model
 - Is there system billing and per-app billing?

 -- Chris


 On Fri, Nov 25, 2011 at 7:26 AM, Jamie Nelson
jamie.nel...@promevo.comwrote:








  How about a header we can append to have a request routed to a
  particular instance-class?

  For those of us using gwt, appending an @Instance(target=a1) or
  @Latency(expected=2500) annotation to rpc methods could append the
  appropriate header to route requests based on their expected latency.

  This would be faster for all of us, and easier on your servers.

  If this feature is released, I will personally write the generator
  patch to implement the annotation {as opposed to have RpcAsync methods
  return RequestBuilder to manually set each request}.

  On Nov 25, 7:01 am, Joshua Smith joshuaesm...@charter.net wrote:
   On Nov 24, 2011, at 12:06 PM, stevep wrote:

Seeing the
many new names from Google in the forums, I'm assuming that is the
case.

   I noticed this, too. Can anyone from google comment (just between us
  girls), is GAE getting some traction inside the googleplex now that
you're
  out of preview? Do you get mentioned in high-level meetings? Are you
  getting some more budget to work with? Are new insanely smart people
  looking to get into your group? Is Brandon's mermaid costume discussed
at
  every water cooler?

   -Joshua

  --
  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
  google-appengine+unsubscr...@googlegroups.com
mailto:google-appengine%2bunsubscr...@googlegroups.com .
  For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.

--
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
google-appengine+unsubscr...@googlegroups.com
mailto:google-appengine%2bunsubscr...@googlegroups.com .
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

 

-- 
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
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Feature Request For Scheduler

[Gopal Patel]

+1 , i wonder if they are already doing it ?

On Wed, Dec 21, 2011 at 10:28 PM, voscausa robert@gmail.com wrote:

 I'll add another patent. Make it inteligent, let it learn from previous
 requests.

 --
 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/-/VTBbeeKybCAJ.
 To post to this group, send email to google-appengine@googlegroups.com.
 To unsubscribe from this group, send email to
 google-appengine+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.


-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: Feature Request For Scheduler

[Brandon Wirtz]

Ok, but describe the method for doing it.  

 

You can't just tack on Let it learn from previous requests and get a
patent. 

 

If so I want a lot of them.

 

Build a Car and Let it learn from previous requests.

Build a Robot Maid and Let it learn from previous requests

Build a search engine and Let it learn from previous requests

 

:-)

 

My example assumes you know more than the scheduler could.

 

If you know that a query returns 50 rows and each row takes 150ms to
process, you can tell the Scheduler how long until you need.

If you get 4 rows on the next request you wouldn't want the scheduler to
learn that the previous request took 12 x as long as this one will.

 

I think I specifically want a Dumber scheduler. That doesn't Learn.

 

 

 

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of voscausa
Sent: Wednesday, December 21, 2011 8:58 AM
To: google-appengine@googlegroups.com
Subject: [google-appengine] Re: Feature Request For Scheduler

 

I'll add another patent. Make it inteligent, let it learn from previous
requests. 

-- 
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/-/VTBbeeKybCAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: Feature Request For Scheduler

[Brandon Wirtz]

Besides feature requests like that end with Skynet.

 

From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of voscausa
Sent: Wednesday, December 21, 2011 8:58 AM
To: google-appengine@googlegroups.com
Subject: [google-appengine] Re: Feature Request For Scheduler

 

I'll add another patent. Make it inteligent, let it learn from previous
requests. 

-- 
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/-/VTBbeeKybCAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request For Scheduler

[voscausa]

I'll add another patent. Make it inteligent, let it learn from previous 
requests.

-- 
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/-/VTBbeeKybCAJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request I Think....

[stevep]

Still voting for task queue optimization. Hopefully we get TQ access
in the /api app. Example, if I get a huge burst of traffic, for
certain types of recs I would much rather build a queue backlog rather
than spin up new 10s latency instances. TQFTW. stevep.

On Nov 29, 11:36 am, Chris Ramsdale cramsd...@google.com wrote:
 Great feedback. Here's the model that I've been envisioning:

 - I have foo.com and foo.com/api
 - foo.com serves up my UI and needs to be super-fast
 - foo.com/api serves up non-realtime API requests
 - both route to a separate App Engine app
 - foo.com has max pending latency of 200ms, and several idle instances
 - foo.com/api has a max pending latency of 10s
 - Each app is part of a larger system that is configurable within the
 Admin Console
 - Being part of a larger system sets up the correct ACLs between apps and
 services (e.g. each app is able talk to the same Datastore)

 A couple of notes:
 - There needs to be a simple way of routing requests. Routing foo.com to
 the system, and configuring paths that map to apps (e.g. /api routes to
 api.foo.appspot.com under the covers is one suggestion)
 - Configurable Memcache that can be shared by each app would be nice, still
 iterating on this one
 - Expose a few more Backend properties to Frontends, and one could imagine
 Backends and Frontends merging under this model
 - Is there system billing and per-app billing?

 -- Chris

 On Fri, Nov 25, 2011 at 7:26 AM, Jamie Nelson jamie.nel...@promevo.comwrote:







  How about a header we can append to have a request routed to a
  particular instance-class?

  For those of us using gwt, appending an @Instance(target=a1) or
  @Latency(expected=2500) annotation to rpc methods could append the
  appropriate header to route requests based on their expected latency.

  This would be faster for all of us, and easier on your servers.

  If this feature is released, I will personally write the generator
  patch to implement the annotation {as opposed to have RpcAsync methods
  return RequestBuilder to manually set each request}.

  On Nov 25, 7:01 am, Joshua Smith joshuaesm...@charter.net wrote:
   On Nov 24, 2011, at 12:06 PM, stevep wrote:

Seeing the
many new names from Google in the forums, I'm assuming that is the
case.

   I noticed this, too. Can anyone from google comment (just between us
  girls), is GAE getting some traction inside the googleplex now that you're
  out of preview? Do you get mentioned in high-level meetings? Are you
  getting some more budget to work with? Are new insanely smart people
  looking to get into your group? Is Brandon's mermaid costume discussed at
  every water cooler?

   -Joshua

  --
  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
  google-appengine+unsubscr...@googlegroups.com.
  For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Feature Request I Think....

[Chris Ramsdale]

On Mon, Dec 19, 2011 at 7:27 PM, James X Nelson jamie.nel...@promevo.comwrote:

 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}.


Great, we're pretty excited about the concepts as well.



 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.


Re: Memcache -- rather than shared Memcache, I more frequently hear the
request for configurable Memcache instances (i.e. please reserve 2GB of
Memcache for app X). Does this resonate with what other folks are
experiencing?

Re: remote api data -- integrating at the data layer has the added
advantage of speed and cleanliness of code.




 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.


Still being fleshed out, but rolled-up pricing seems to be a natural fit.



 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. =}


Sure thing, and thanks for the feedback. Keep it coming!

-- Chris




 --
 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 google-appengine@googlegroups.com.
 To unsubscribe from this group, send email to
 google-appengine+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.


-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Feature Request I Think....

[James X Nelson]

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 google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Re: [google-appengine] Re: Feature Request I Think....

[Chris Ramsdale]

Great feedback. Here's the model that I've been envisioning:

- I have foo.com and foo.com/api
- foo.com serves up my UI and needs to be super-fast
- foo.com/api serves up non-realtime API requests
- both route to a separate App Engine app
- foo.com has max pending latency of 200ms, and several idle instances
- foo.com/api has a max pending latency of 10s
- Each app is part of a larger system that is configurable within the
Admin Console
- Being part of a larger system sets up the correct ACLs between apps and
services (e.g. each app is able talk to the same Datastore)

A couple of notes:
- There needs to be a simple way of routing requests. Routing foo.com to
the system, and configuring paths that map to apps (e.g. /api routes to
api.foo.appspot.com under the covers is one suggestion)
- Configurable Memcache that can be shared by each app would be nice, still
iterating on this one
- Expose a few more Backend properties to Frontends, and one could imagine
Backends and Frontends merging under this model
- Is there system billing and per-app billing?

-- Chris

On Fri, Nov 25, 2011 at 7:26 AM, Jamie Nelson jamie.nel...@promevo.comwrote:

 How about a header we can append to have a request routed to a
 particular instance-class?

 For those of us using gwt, appending an @Instance(target=a1) or
 @Latency(expected=2500) annotation to rpc methods could append the
 appropriate header to route requests based on their expected latency.

 This would be faster for all of us, and easier on your servers.

 If this feature is released, I will personally write the generator
 patch to implement the annotation {as opposed to have RpcAsync methods
 return RequestBuilder to manually set each request}.

 On Nov 25, 7:01 am, Joshua Smith joshuaesm...@charter.net wrote:
  On Nov 24, 2011, at 12:06 PM, stevep wrote:
 
   Seeing the
   many new names from Google in the forums, I'm assuming that is the
   case.
 
  I noticed this, too. Can anyone from google comment (just between us
 girls), is GAE getting some traction inside the googleplex now that you're
 out of preview? Do you get mentioned in high-level meetings? Are you
 getting some more budget to work with? Are new insanely smart people
 looking to get into your group? Is Brandon's mermaid costume discussed at
 every water cooler?
 
  -Joshua

 --
 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
 google-appengine+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/google-appengine?hl=en.



-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request I Think....

[Jamie Nelson]

How about a header we can append to have a request routed to a
particular instance-class?

For those of us using gwt, appending an @Instance(target=a1) or
@Latency(expected=2500) annotation to rpc methods could append the
appropriate header to route requests based on their expected latency.

This would be faster for all of us, and easier on your servers.

If this feature is released, I will personally write the generator
patch to implement the annotation {as opposed to have RpcAsync methods
return RequestBuilder to manually set each request}.

On Nov 25, 7:01 am, Joshua Smith joshuaesm...@charter.net wrote:
 On Nov 24, 2011, at 12:06 PM, stevep wrote:

  Seeing the
  many new names from Google in the forums, I'm assuming that is the
  case.

 I noticed this, too. Can anyone from google comment (just between us girls), 
 is GAE getting some traction inside the googleplex now that you're out of 
 preview? Do you get mentioned in high-level meetings? Are you getting some 
 more budget to work with? Are new insanely smart people looking to get into 
 your group? Is Brandon's mermaid costume discussed at every water cooler?

 -Joshua

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request I Think....

[stevep]

There are two schedulers already at work I believe. On-line handler
and Task Queue. TQ is, I believe, optimized for longer running tasks.
Google has never to my knowledge explained how these two schedulers
interact managing load inside the current instance setup. I long, long
ago posited that by changing TQ moderately there would be
opportunities substantial system optimizations. That is a complete
guess, however, knowing nothing about how the system works. Anyway, I
believe TQ is the ignored, red-headed step-child within GAE. Perhaps
initiated by a brilliant engineer who left, and no one wants to visit
his/her code. Alternatively, it could have been a quick idea hack that
everyone wants to deprecate and dispose of. Ultimately GAE today is
clearly a version one. At the very least it would make sense for the
OL Scheduler to analyze calls individually, but I don't think it does
that based on a previous thread Brandon started about one very high
latency function effecting a higher-than-necessary instance count.
Hopefully the initial financials for GAE are promising, and these
types of issues will get the great minds at G. applied. Seeing the
many new names from Google in the forums, I'm assuming that is the
case.

On Nov 24, 1:39 am, Brandon Wirtz drak...@digerat.com wrote:
 I probably need more time for testing but.

 It would appear that putting slow tasks on one app and fast tasks on the
 other DRASTICALLY reduces the number of required instances.

 I suspect that requests that take less than 200ms don't support concurrency,
 and requests that take more than 1500 support a lot.

 So when they co-exist on the same instances the fast instances don't stack
 well, and the long requests create large delays.  Basically what was
 requiring 8-10 instances now takes 4.  Some of that may just be that my ram
 usage lets me hit instance memory more often in the segmented apps because I
 have less total data passing through instances.

 This makes a strong case for being able to specify Handlers to specific
 instances, and having different Scheduler settings for various handlers.

 Brandon Wirtz
 BlackWaterOps: President / Lead Mercenary

 Description:http://www.linkedin.com/img/signature/bg_slate_385x42.jpg

 Work: 510-992-6548
 Toll Free: 866-400-4536

 IM: drak...@gmail.com (Google Talk)
 Skype: drakegreene

  http://www.blackwaterops.com/ BlackWater Ops

 From: google-appengine@googlegroups.com
 [mailto:google-appengine@googlegroups.com] On Behalf Of Brandon Wirtz
 Sent: Wednesday, November 23, 2011 5:13 PM
 To: google-appengine@googlegroups.com
 Subject: RE: [google-appengine] Feature Request I Think

 It will be a while before I'm certain, but it looks like separating long and
 short requests saves me a LOT on instance $$$.  I'm guessing that volume
 and average request time don't get calculated well when the types of
 requests change, so when site X gets crawled by Google Bot the scheduler
 tunes for one setting, and why Y gets crawled it gets tune another way, and
 when both get crawled at the same time all hell breaks loose.

 Latency by IP Range would be S awesome :-) those Google bots don't need
 the same QoS as my Paying customers :-)

 From: google-appengine@googlegroups.com
 [mailto:google-appengine@googlegroups.com] On Behalf Of Brandon Wirtz
 Sent: Wednesday, November 23, 2011 4:58 PM
 To: google-appengine@googlegroups.com
 Subject: RE: [google-appengine] Feature Request I Think

 Chris,

 For my app sharing data would not be an issue.  That is one of the reasons
 I'm considering (and testing) using more than one App so that I can have
 different Scheduler/Instance/Latency settings in each.

 In my case most of the difference is per domain, but I do know for instance
 that everything in with a ?s=Keyword is a Search and will therefor take
 longer than just returning some page with some data.

 The reason I was looking at Per Handler was that I was hoping that
 something could be done where it was just instance balancing.  I would have
 2 instances reserved for Priority 0 requests and 1 for p1 requests.

 If P0 is busy, and p1 is not p1 serves p0 requests.

 If P0 is busy and P1 is busy more P0 instances spin up

 If P1 is busy more P1 instances spin up.

 But the busy state for each would be configurable.

 If P0 Request has 133 ms pending Latency set  and p1 has 1000 ms Pending
 latency

 Then the waterfall would look something like this..

 P0 Request

 Instance 1 has 166ms until free  - go next

 Instance 2 has 266ms until free  - go next

 Instance 3 is p1 handler has 106ms until free  - serve request

 P0 Request

 Instance 1 has 166ms until free  - go next

 Instance 2 has 266ms until free  - go next

 Instance 3 is p1 handler has 1206ms until free  - Create new P0 Instance

 Instance 4 is P0 - serve request

 P1 Request

 Instance 1 is not P1 has 166ms until free  - go next

 Instance 2 is not P1 has 266ms until free  - go next

 Instance 3 is p1 handler has 106ms until free  - serve 

[google-appengine] Re: Feature Request I Think....

[Andrei Volgin]

Allowing several apps to talk to the same Datastore may be a good idea
in its own right, but it would the wrong way to look at this issue.
Most apps combine slow and fast requests in a way that makes them hard
to separate. If I can specify that requests A, B and C go to instance
type 1, and request D goes to instance type 2, then I can expect
significant performance improvements by being able to fine-tune each
type of front-end instances. I would love to be able to set different
rules for each type as I know when my users expect an immediate
response and when a few seconds delay is not a problem.

We already take advantage of the two tiers of instances: frontend and
backend. This idea takes it one step further by creating custom
frontend instance types. While you are at it, maybe you can get rid of
these artificial monikers of frontend and backend instances, and
have a single implementation that lets us define our own instance
types based on 3-4 criteria.

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request to Switch Accounts at the Dashboard

[Francois Masurel]

I've starred the related issue :

http://code.google.com/p/googleappengine/issues/detail?id=6018

-- 
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/-/tA0O2Q456PkJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request to Switch Accounts at the Dashboard

[Tapir]

You can use 2 different browsers,

On Oct 1, 8:45 pm, Joshua Smith joshuaesm...@charter.net wrote:
 6018

 If you, like me, wear multiple hats (professional and pro-bono), and keep 
 them separate with separate accounts, then you, like me, find it really 
 annoying to switch between those hats in the dashboard. Please star my 
 feature request.

 Thanks.

 -Joshua

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

RE: [google-appengine] Re: Feature Request to Switch Accounts at the Dashboard

[Brandon Wirtz]

Incognito window works well.  I use Chrome for Login A, and Chromium for
Login b that works well too.


-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of Tapir
Sent: Saturday, October 01, 2011 5:09 PM
To: Google App Engine
Subject: [google-appengine] Re: Feature Request to Switch Accounts at the
Dashboard

You can use 2 different browsers,

On Oct 1, 8:45 pm, Joshua Smith joshuaesm...@charter.net wrote:
 6018

 If you, like me, wear multiple hats (professional and pro-bono), and keep
them separate with separate accounts, then you, like me, find it really
annoying to switch between those hats in the dashboard. Please star my
feature request.

 Thanks.

 -Joshua

-- 
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
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.


-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request: Custom (sub)domain to a version subdomain mapping

[Julian Namaro]

The issue below is related:
http://code.google.com/p/googleappengine/issues/detail?id=2878

For apps using custom domains having to test different versions on
appspot.com can cause problems with cookies and OpenID identities.



On Apr 26, 9:21 pm, Vladimir Prudnikov v.prudni...@gmail.com wrote:
 It would be great to be able to map a custom domain or subdomain to a
 version  subdomain (version-name.app-id.appspot.com).

 In my situation I have a website running on Python SDK and API running on
 Java SDK. So,www.mydomain.compoints to the default version subdomain
 master.app-id.appspot.com and api.mydomain.com points to the another version
 api.app-id.appspot.com.

 The advantages are:
 + I can deploy a master version more often and it will not affect API
 + I can use both Python and Java SDK in one app and using the same database
 + Many subprojects can use the same database
 + I can limit access to the API's codebase for a developers who work on a
 website, so he can deploy a website without having an API code.
 + anything else?

-- 
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 
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

[google-appengine] Re: Feature Request: Amazon DevPay equivalent

[David Sowerby]

Great idea - would it be better recorded as an issue so we can all
vote for it?  (could be that there is one there already of course ...)

David

On Oct 30, 5:42 pm, vacorda victoraco...@gmail.com wrote:
 I would really love GAE to offer a service similar to Amazon 
 DevPay.http://aws.amazon.com/devpay/

--~--~-~--~~~---~--~~
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 
google-appengine+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~--~~~~--~~--~--~---

[google-appengine] Re: Feature Request?

[Josh Heitzman]

I wouldn't want the item deleted until I had done whatever processing
I needed to do with its data to ensure it didn't get lost due to a
raised exception or crashed machine.

On Oct 17, 9:18 am, Ethan Post [EMAIL PROTECTED] wrote:
 A common task (queueing) is fetchitem...delete the item once it has been
 fetched. Right now that requires a get/fetch and a call to db.delete at
 some point. It would be nice if there was a particular attribute that could
 be set in the get which would automatically delete the item once it has been
 fetched. Google could figure out the most efficient mechanism for doing this
 on the backend and we end up saving mcycles by not having to call the delete
 for this type of db request.

 Stupid? Not stupid? Would anyone else like this feature?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Feature Request?

[Ethan Post]

I understand the concern. This would be just be an option, you would likely
not have the same degree of assurance that the item has actually been read
without error. Just looking for ways to keep mcycles down which G must be
very concerned about based on the low thresholds they have set up for
warnings. Based on elapsed time (I can not get mcycle info per call/code
unit) it appears puts and deletes probably utilize the most mcycles. I would
be fine with this feature even if I lose some data for my purposes. I guess
I could skip the datastore entirely for some features and use memcache,
which I might do, I just have not had time to play around with that yet.

On Fri, Oct 17, 2008 at 11:24 AM, Josh Heitzman [EMAIL PROTECTED]wrote:


 I wouldn't want the item deleted until I had done whatever processing
 I needed to do with its data to ensure it didn't get lost due to a
 raised exception or crashed machine.




--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Feature Request?

[Wooble]

On Oct 17, 12:52 pm, Ethan Post [EMAIL PROTECTED] wrote:
 I guess
 I could skip the datastore entirely for some features and use memcache,
 which I might do, I just have not had time to play around with that yet.

It's almost certainly a bad idea to rely on memcache for a queue;
there's no guarantee that what you put in will come out when you want
it.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[google-appengine] Re: Feature Request?

[Ethan Post]

Understood, but I am interested in seeing what sort of hit/miss ratio I get.
There are uses and ways to design around data loss (for example, sequential
#'s would be expected by the reader, a miss would end up generating a write
to the datastore which could be monitored by the sender to trigger a resend.
I know the design would not be ideal but I sort of like the challenge of
staying under those cpu thresholds!

On Fri, Oct 17, 2008 at 2:13 PM, Wooble [EMAIL PROTECTED] wrote:




 On Oct 17, 12:52 pm, Ethan Post [EMAIL PROTECTED] wrote:
  I guess
  I could skip the datastore entirely for some features and use memcache,
  which I might do, I just have not had time to play around with that yet.

 It's almost certainly a bad idea to rely on memcache for a queue;
 there's no guarantee that what you put in will come out when you want
 it.
 


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---