Transcript: App Engine chat time Nov 5
12 views
Skip to first unread message
Marzia Niccolai
Nov 6, 2008, 2:14:11 PM11/6/08
to Google App Engine
danielobrien: On that note, welcome everyone to the second App Engine chat session. We have a few Googlers here besides myself: marzia_google and dan_google.
[7:02pm] moraes: "Enter a valid Austrian Social Security Number in XXXX XXXXXX format." -> locales are curious
[7:02pm] cresloyd joined the chat room.
[7:02pm] danielobrien: This is intended as a pretty informal session, so just ask questions and hopefully we'll catch all of them.
[7:03pm] marzia_google: i'll take the ToS question, as long as it's understood that IANAL
[7:03pm] brian_skinner:
[7:03pm] brian_skinner: The terms say "You must provide legally adequate privacy notice and protection for those users", and "You agree to set up a process to respond to notices of alleged infringement that comply with the United States' Digital Millennium Copyright Act"
[7:03pm] Dado1: IANAL sounds like a bad word to me
[7:03pm] brian_skinner: http://code.google.com/appengine/terms.html
[7:04pm] marzia_google: IANAL = i am not a lawyer
[7:04pm] brian_skinner: Is there a simple example anywhere that shows what I need to do to make sure my website complies with the terms? Like, in the App Gallery, is there an example app with a minimally conforming privacy notice and DMCA process notice?
[7:04pm] Dado1:
[7:04pm] danielobrien: peterr: It depends on the type of support you're looking for. There will be some additional support for billing-related issues.
[7:05pm] marzia_google: oh, this is definitely a question for a lawyer
[7:05pm] peterr: ok. any comment on the scary stories of people getting locked out of their google accounts? should I create a seperate account for my app engine work?
[7:05pm] brian_skinner: okay, thanks marzia_google -- thought I'd try here
[7:06pm] marzia_google: so, loosing access to google account does not affect how your app would run
[7:06pm] danielobrien: peterr: We *are* constantly trying new things though. Like these chat sessions.
[7:06pm] marzia_google: it would affect your personal ability to log in to any service that uses google accounts, but perhaps have multiple admins on your app?
[7:06pm] pranny: What is the difference between keys and IDs. As far as my perception goes, keys are manually assigned, while IDs are assigned automatically if we don't specify a key value. I fear I might be wrong.
[7:06pm] Dado1: Will GAE limitations/quotas on file size and request timeout ever be lifted/relaxed for paying customers to make them able to design applications that handles sizable binary files (1-10Mb) on average?
[7:07pm] dan_google: pranny: You got it.
[7:07pm] jcgregorio joined the chat room.
[7:07pm] Dado1: pranny: key_names are manually assigned, ID are automatically assigned... key_names or ID then becomes part of the key
[7:07pm] jcgregorio: hello, sorry for being late
[7:07pm] pranny: Okay, I got it
[7:08pm] marzia_google: keys also contain information about the ancestor path
[7:08pm] dan_google: pranny: More specifically, the "key" is what uniquely identifies the entity. A key can have either an app-assigned key_name or a system-assigned ID.
[7:08pm] marzia_google: so you can generate a key given the ancestor
[7:08pm] marzia_google: so for instance key.from_path()
[7:08pm] marzia_google: http://code.google.com/appengine/docs/datastore/keyclass.html
[7:09pm] pranny: Okay, Thanks
[7:09pm] danielobrien: Dado1: I think this overlaps with your previous question? File sizes being relaxed are on our roadmap for within the next two quarters, and when implemented, would affect both paying and non-paying users.
[7:09pm] Dado1: daniel: but that is intrinsically tied to the request/response timeout
[7:09pm] danielobrien: Dado1: The quotas relevant to billing are those on the "Understanding Quotas" page. Others, like request timeouts and file sizes, are more technical limitations.
[7:10pm] ribrdb joined the chat room.
[7:10pm] Dado1: daniel: when I saw that google positioned appengine storage charges in line with Amazon S3 I thought I could you use GAE as a supercharged S3
[7:11pm] darren__: I am concerned about datastore backup. Will there be an solution provided soon or will we have to continue with our own methods? Also, will there be be any google service for datastore work such as data rollback etc?
[7:11pm] Dado1: and that I could store as much as I wanted (per file and per app) by paying for it
[7:11pm] marzia_google: darren__ bulk upload and download are on the roadmap for the next two quarters
[7:11pm] darren__: cool
[7:11pm] Dado1: daniel: but I keep coming across a phantomatic "Python variable size limit of 1Mb" which I still don't quite understand!!!
[7:12pm] pr3d4t0r: marzia_google: . o O o .
[7:12pm] marzia_google: for longer term things such as data rollback, that is nice to have, but not a current priority
[7:12pm] pr3d4t0r: marzia_google: Howdy
[7:12pm] marzia_google: hello
[7:12pm] pr3d4t0r: marzia_google: To what do we owe the pleasure?
[7:12pm] marzia_google: oh it's app engine chat time
[7:12pm] • pr3d4t0r checks the calendar.
[7:13pm] pr3d4t0r: marzia_google:
[7:13pm] danielobrien: Dado1: Understood. Dealing with large files at all requires relaxing those limits, so I suspect it's part of the goal in increasing the actual file size limits.
[7:13pm] • pr3d4t0r STFU and listens.
[7:13pm] marzia_google: ah well we welcome all questions
[7:13pm] marzia_google: so listening is nice, but participation is also great
[7:13pm] marzia_google:
[7:13pm] danielobrien: That isn't to say we'll necessarily remove the limits of urlfetch, datastore operations, python computation, etc.
[7:14pm] troy_google joined the chat room.
[7:14pm] marzia_google: i think the thing to realize is that the http response limit will still exist, but there will also be support for longer running requests, large file uploads
[7:14pm] darren__: will the docs be improved, with more examples. I am getting there with it but its bad for my head!
[7:14pm] marzia_google: so there will be a bit of both
[7:15pm] dan_google: darren__: docs are steadily being improved
[7:15pm] Dado1: marzia/daniel: ok, good
[7:15pm] dan_google: darren__: we hear the need for more examples loud and clear
[7:15pm] jcgregorio: yes, we've got more articles in the pipeline
[7:15pm] dan_google: darren__: though we're also busy documenting new features.
[7:16pm] darren__: that would be great. Thanks guys
[7:16pm] • pr3d4t0r is busy working on that.
[7:16pm] minishark: Are there any plans to add more Google services to the Google Data APIs?
[7:16pm] jcgregorio: darren__: anything in particular you want to see expounded upon?
[7:16pm] danielobrien: minishark: It's already possible to access them using the Google Data python libraries.
[7:16pm] Dado1: I posted a ticket a while back regarding adding a Unique=True/False arg to the property constructor/declaration, like it is done in Djiango models... any thought on that? Any solution as to how to ensure a property value is unique across a datastore (email address for example)???
[7:17pm] darren__: all the datastore section especially
[7:18pm] peterr: can you add a 52 point bold flashing headline somewhere that says "GQL is not SQL"?
[7:18pm] ribrdb: Dado1: the best way to ensure uniqueness is to use the property as a key_name
[7:18pm] brett_google joined the chat room.
[7:19pm] dan_google: <blink style="font-size: 52px">GQL is not SQL.</blink>
[7:19pm] marzia_google: peterr: flashing and i'm thinkng maybe some kind of song to go with it
[7:19pm] Dado1: ribrdb: that works if the value is immutable... but for say, a user email address that can change that doesn't work!!!
[7:19pm] marzia_google: perhaps eye of the tiger..
[7:19pm] darren__:
[7:19pm] brett_google: heyo
[7:19pm] jcgregorio: minishark: there's an ongoing effort to add Google Data APIs to new products, but obviously I can't comment on which ones are being worked on, or any timing like that
[7:20pm] jcgregorio: minishark: (I worked with the Google Data APIs group before joining the App Engine team)
[7:20pm] jcgregorio: hey brett_google
[7:20pm] brett_google: hey joe
[7:20pm] marzia_google: we've had several more googlers join us since introductions
[7:20pm] danielobrien: Dado1: At present, outside of using key_name, the only option is a manual uniqueness check.
[7:21pm] ironfroggy_ left the chat room. ("http://www.mibbit.com ajax IRC Client")
[7:21pm] brett_google: sorry for being late
[7:21pm] jcgregorio: jcgregorio == Joe Gregorio, Developer Advocate for App Engine
[7:21pm] minishark: I was mostly just interested in the Google Analytics API, which I know is in private beta right now. Hopefully it'll be rolled out to everyone soon.
[7:21pm] marzia_google: i would say you were fashionable, brett
[7:21pm] Dado1: daniel: I tried that, but not being able to query inside a transaction doesn't ensure uniqueness, even if a manual check is done
[7:21pm] jcgregorio: and only a couple minutes later than me
[7:22pm] ribrdb: Dado1: you could probably make it work by creating a new entity when they change the email address.
[7:23pm] brett_google:
[7:23pm] Dado1: ribrdb: sure, but I will then have to update all references to it... and it would also screw up the entity groups etc
[7:24pm] Dado1: I think a UNIQUE index options would do, if in any way possible
[7:24pm] minishark: What are your plans for supporting Python 3.0 when it comes out?
[7:25pm] minishark: bc it's not backwards compatible
[7:25pm] brett_google: minishark: guido has said before that we're going to consider it a totally separate language
[7:25pm] brett_google: because of that issue, among other things
[7:25pm] danielobrien: When we introduce backward-incompatible changes we'd also require a version change in app.yaml.
[7:26pm] brett_google: in terms of an api version, right
[7:26pm] brett_google: but in this case it would need to be a separate runtime, because the language is fundamentally not backwards compatible
[7:26pm] danielobrien: Yep, makes sense.
[7:26pm] r0ver left the chat room. ("Leaving.")
[7:27pm] peterr: oh i see. the "new language" we're getting is really just python 3.0!
[7:27pm] Dado1: Ruby please!!!
[7:27pm] brett_google: haha
[7:27pm] marzia_google: FORTRAN77 please
[7:27pm] brett_google: oh i don't know we'll see
[7:27pm] danielobrien: No Cobol?
[7:27pm] Dado1: Lisp
[7:27pm] • jcgregorio secretly wants Forth
[7:27pm] moraes: smalltalk, please
[7:28pm] dan_google: 6502 assembly please
[7:28pm] Dado1: erlang
[7:28pm] minishark: I want Logo so I can make that little turtle draw pictures
[7:28pm] ribrdb: Dado1: In my app I do something like this by having a separate entity that I only use for checking uniqueness. I still store the data in a regular property too. Something like that might work for you.
[7:28pm] r0ver joined the chat room.
[7:28pm] darren__: why are these chats so late? not great for us in Europe!
[7:28pm] marzia_google: we alternate
[7:28pm] dan_google: minishark: http://www.cologo-lang.org/
[7:28pm] peterr: they alternate times darren
[7:28pm] marzia_google: mornings and evenings
[7:29pm] marzia_google: 1st weds of the month 7-8
[7:29pm] marzia_google: 3rd 9-10am
[7:29pm] marzia_google: all pacific time
[7:29pm] marzia_google: that would be 3rd weds of the month
[7:29pm] minishark: haha that's awesome. really takes me back to elementary school!
[7:29pm] darren__: righto - nice
[7:30pm] brett_google: marzia: so did you already ask if anyone's got an app they want to show off?
[7:30pm] marzia_google: oh we haven't
[7:30pm] marzia_google: but
[7:30pm] marzia_google: that's a great question
[7:30pm] marzia_google: which you just asked
[7:30pm] Dado1: ribrdb: sure, but once you have check uniqueness with that special entity, how do you know somebody is not adding the same value in a standard entity while you are transferring it from the special entity to the one holding the value in a standard property???
[7:30pm] jcgregorio: Dado1: are you trying to protect a single property so it can never be changed to match another value already in the store?
[7:31pm] Dado1: jcgregorio: yes, both at create and update time
[7:31pm] jcgregorio: and you'd also like to do exact matches on that property in queries?
[7:32pm] Dado1: jcgregorio: that's already possible... what I would like is to have a UNIQUE index of some sort
[7:33pm] Dado1: jcgregorio: sure, something like Model.get_or_insert_by_uniquepropertyname() would be nice too!
[7:34pm] Dado1: jcgregorio: like dynamic finders in Rails
[7:34pm] Dado1: jcgregorio: but I mostly worried about data integrity
[7:34pm] jcgregorio: ok, not familiar with dynamic finders in Rails
[7:34pm] Dado1: and duplication
[7:35pm] darren__ left the chat room.
[7:36pm] marzia_google: so, how would get_or_insert_by_uniquepropertyname differ from get_or_insert_by_key_name?
[7:36pm] marzia_google: in your design?
[7:36pm] jcgregorio: right, but unless they're in the same entity group you can't enforce what happens in other entities
[7:36pm] Dado1: marzia: key_name is immutable after creation, emai addresses aren't
[7:37pm] marzia_google: right so, you want a uniquepropertyname that is changeable?
[7:37pm] marzia_google: but still unique?
[7:37pm] brett_google: so yeah you'd need an intermediary entity
[7:37pm] Dado1: marzia: you got it!
[7:38pm] brett_google: ah just read the earlier chat
[7:38pm] brett_google: i understand the issue
[7:39pm] Dado1: marzia: http://docs.djangoproject.com/en/dev/topics/db/models/#field-options
[7:40pm] Dado1: marzia: something like the Djiango field property unique would be very welcomed
[7:41pm] brett_google: i think that's probably possible within a single entity kind
[7:41pm] brett_google: fundamentally with bigtable
[7:41pm] brett_google: doing it cross-kind would be more difficult
[7:41pm] Dado1: brett_google: I only need it within a single entity kind... like in djiango, unique only applies within a single table
[7:42pm] brett_google: yeah it's a cool idea
[7:42pm] brett_google: theoretically you could do it for any index in the index.yaml file
[7:42pm] Dado1: brett_google: any orm I've seen out there supports a unique modifier for properties
[7:43pm] brett_google: so you could do uniqueness on a composite index
[7:43pm] Dado1: brett_google: exactly, you're reading my mind... composite unique key would also be nice
[7:43pm] brett_google: sounds like a great issue to open
[7:43pm] danielobrien: Yep, we already have it in the issue tracker. It's fairly popular, going by stars.
[7:43pm] Dado1: I opened it very soon after gae launched
[7:44pm] brett_google: cool
[7:44pm] danielobrien: In case it hasn't been posted already: http://code.google.com/p/googleappengine/issues/detail?id=178
[7:45pm] Dado1: dado is short for edoardo
[7:45pm] marzia_google: i think it's an interesting feature request, i think it touches on a theme we talked a lot about in the first chat which is prioritizing requests
[7:45pm] Dado1: dynamic generated methods like Model.get_by_uniquepropertyname would then be easy to do
[7:46pm] Dado1: like User.get_by_email
[7:46pm] Dado1: I am not talking about the google appengine users.User... but a custom one
[7:47pm] marzia_google: sure, i think with all feature requests, if i may quote myself from last time quoting ryan
[7:47pm] marzia_google: 'we love them all equally, but we have to work on one (or a few) at a time'
[7:47pm] marzia_google: so the team is also working on the features like ability to pay for more quota
[7:47pm] marzia_google: and large file uploads
[7:47pm] marzia_google: offline processing
[7:47pm] marzia_google: system stability
[7:47pm] marzia_google: etc
[7:48pm] Dado1: marzia: I just thought that this is such a common thing in databases that google big table already implements it
[7:49pm] Dado1: large file uploads and offline processing are a MUST!!! but unique indexes I thought would have been already done in bigtable by google for their on sake
[7:50pm] peterr: do the appengine folks follow EC2 and other cloud projects out there closely, or do you mostly just worry about appengine?
[7:51pm] Dado1: peterr: windows azure seems more similar to GAE than EC2/S3
[7:51pm] marzia_google: i think that the key is to decouple traditional relational databases and the datastore in your mind
[7:51pm] brett_google: dado1: bigtable's nothing but unique indexes, since it just maps row keys to value columns; this comes more into play with how bigtable works together with the Datastore API; you can watch ryan's talk from Google I/O for more details on the way the composite indexes work
[7:52pm] moraes left the chat room. (Read error: 104 (Connection reset by peer))
[7:52pm] jeffr joined the chat room.
[7:52pm] troy_google: I follow them in my personal time closely out of general interest in the field
[7:52pm] Dado1: brett_google: that's exactly why I thought exposing it in the datastore api would require much effort... but I am probably very wrong since I am a neuroscientist during the day, and the programmer just for few hours during the night
[7:53pm] Dado1: brett_google: I meant WOULDN'T require much effort
[7:53pm] marzia_google: yeah i was going to say i think that all of us on the app engine team are interested and excited by all the different things going on in this field
[7:53pm] moraes joined the chat room.
[7:54pm] brett_google: dado1: it sounds like a good fit and is clearly useful
[7:54pm] marzia_google: i think also when it comes to adding features and things, the key to remember is that what is maybe a conceptual easy change still takes lots of time to implement
[7:54pm] marzia_google: write design test
[7:54pm] marzia_google: etc
[7:55pm] Dado1: marzia: sure!!! on that issue... how big is the GAE team... in term of developers?
[7:56pm] jeffr: any progress on the GAE latency issues when using a non appspot domain?
[7:57pm] marzia_google: i think that number is hard to guage really accurately, because there are app engine developers, contributors, and contributors to the services like big table app engine uses
[7:58pm] Dado1: marzia: just GAE developers
[7:58pm] Dado1: marzia: more or less
[7:59pm] Dado1: one more thing... any progress on a real fulltext search api (using the full google power)???
[8:00pm] Dado1: I mean full text search of model properties
[8:00pm] binarybandit left the chat room. ("Later")
[8:00pm] marzia_google: officially we don't generally give out specific staffing numbers, but i can say that it's def bigger than dan_google, brett_google, troy_google, danobrien, ribrdb and jcgregorio that are here tonight
[8:00pm] marzia_google: so
[8:00pm] marzia_google:
[8:00pm] Dado1: got it
[8:01pm] marzia_google: ah that's something that we are definitely looking in to as well
[8:01pm] marzia_google: fulltext search
[8:01pm] danielobrien: jeffr: Not that I'm aware of. It isn't something we've forgotten about though.
[8:01pm] Dado1: it would be nice in the gae group to know when we are talking to gae dev team members... with an icon or something
[8:01pm] jeffr: sweet
[8:01pm] marzia_google: yeah, i'm not sure that irc supports that
[8:02pm] Dado1: marzia: no, I mean in the google group... amazon does it in its dev forums
[8:02pm] danielobrien: We could bug one of the ops to have us all voiced for next time, possibly? Or just adopt the _google suffix.
[8:02pm] Dado1: the suffix would work!
[8:02pm] marzia_google: oh in the forums, yes the @google email address is subtle
[8:02pm] marzia_google: and the problem with adding something to your profiel in groups is that if you post by email (like me) it doesn't actually work
[8:03pm] danielobrien: For the forums, some of us add "(Google)" to our names. Certain Google Groups also support more complex badging.
[8:03pm] danielobrien: It means a fairly major change to the groups though.
[8:03pm] marzia_google: yeah, the (Google) thing only works if you post through the groups UI
[8:03pm] Dado1: I think a suffix like gae_team would work well
[8:04pm] marzia_google: perhaps we could also post an introduction to known google posters
[8:04pm] Dado1: yes, perhaps in a (hopefully) upcoming FAQ
[8:04pm] danielobrien: I know we want to avoid cluttering the main groups page, but it may also fit there.
[8:05pm] danielobrien: Oh, and since it's past 8:00 the chat is officially over. I suspect a few of us will still be around though.
[8:06pm] minishark left the chat room. ("Leaving")
[8:06pm] Dado1: it would be nice, if allowed by the developers, to look at the source of appengine apps
[8:06pm] danielobrien: Your own apps, or other people's?
[8:06pm] Dado1: as an option for the app
[8:06pm] peterr: thanks to all the gae folks for being available
[8:07pm] peterr left the chat room.
[8:07pm] moraes: oooh. just found http://code.google.com/p/googleappengine/issues/detail?id=113. i didn't know that. my app is totally expecting to deal with wilcards.
[8:07pm] marzia_google: thanks everyone for coming
[8:07pm] Dado1: other people
[8:07pm] brett_google: dado1: well there's this one: http://shell.appspot.com/
[8:07pm] pranny: Thanks GAE team
[8:07pm] brett_google: and it has the link on the upper right
[8:07pm] danielobrien: Source privacy is a big concern for a lot of people, so it would definitely need to be optional.
[8:07pm] brett_google: not too hard to do it yourself like that; but it'd be cool if it were automatic
[8:07pm] Dado1: brett: thanx
[8:07pm] Dado1: daniel: definitively optional
[8:07pm] marzia_google: and it would be a good time to plug version control and open source software development
[8:08pm] marzia_google: as good existing solutions
[8:08pm] danielobrien: Since I also work on project hosting I'm inclined to point people to that, which has its own source browsing.
[8:09pm] Dado1: it would nice if, on a opt-in basis, a gae app would be sync'ed with a google code project
[8:10pm] Dado1: for example when using appcfg update
[8:10pm] marzia_google: yes, that would be totally cool
[8:10pm] danielobrien: Yep, that's another popular feature request. Better source control integration in general on top of that.
[8:11pm] Dado1: please add git support to google code
[8:11pm] marzia_google: totally off topic, but if you have google apps, you can add rietveld using apps labs
[8:11pm] marzia_google: which is generally pretty awesome
[8:11pm] marzia_google: or rather 'google code reviews'
[8:11pm] marzia_google: http://www.google.com/enterprise/marketplace/viewListing?productListingId=5143210+12982233047309328439
[8:12pm] danielobrien: Yep, git's another popular request. You're probably getting tired of me saying that without giving a position.
[8:13pm] Dado1: how about a polling system to prioritize feature requests? the star system is annoying... given that you get all those +1 emails
[8:14pm] marzia_google: well people shouldn't +1 and star
[8:14pm] marzia_google: ...
[8:14pm] marzia_google: i think starring should not email everyone on this list
[8:14pm] brian_skinner_ joined the chat room.
[8:14pm] Dado1: marzia: you're right... but people still voted almost 50% for a republican after 8 years of Bush
[8:15pm] danielobrien: Yeah, that's on the project hosting team's feature request list. It's another one of those prioritization issues though.
[8:15pm] brett_google: alright time to go; have a good one everybody
[8:15pm] jeffr_ joined the chat room.
[8:15pm] brett_google left the chat room. ("peaceout")
[8:15pm] danielobrien: Perhaps refine down to a shorter list and use Google Moderator or something?
[8:15pm] Dado1: danielobrien: exactly
[8:16pm] brian_skinner_ left the chat room. (Client Quit)
[8:16pm] danielobrien: Actually, with project hosting's recently added support for embedded gadgets there may be a solution there.
[8:17pm] danielobrien: I should probably get off the project hosting tangent though.
[8:18pm] jeffr_: i notice that when i deploy my app, there are a few seconds where my app is inaccessible - what is the best way to deploy to avoid this?
[8:18pm] marzia_google: versioning of your app
[8:18pm] jeffr_: is there a way to automate this?
[8:18pm] jeffr_: i think i am on my 1000th revision of my app
[8:18pm] marzia_google: actually i would suggest also, if you are adding new indexes, run update_indexes before uploading your app
[8:19pm] marzia_google: oh well, the only way currently is to manually update hte version in app.yaml
[8:19pm] danielobrien: I suspect you could just swap back and forth between live versions?
[8:19pm] marzia_google: i'm sure clever people could write a great build script to take care of that for you
[8:19pm] Dado1: would the suggested workflow be vacuum + update indexes, then update app?
[8:19pm] jeffr_: it would be awesome if i could just press one button
[8:19pm] jeffr_: like i do now
[8:20pm] marzia_google: there is really no need to vacuum indexes
[8:20pm] marzia_google: unless you are getting close to 100 and not using one any more
[8:20pm] Dado1: marzia: ok, thanx
[8:20pm] marzia_google: well you can press a button to deploy, but not to edit the app.yaml
[8:21pm] troy_google: jeffr: we are aware of that problem and I believe we do have a solution to make it better ... however daniel and marzia's solution is the preferred method for the time being
[8:21pm] You left the chat by being disconnected from the server.
[8:22pm] You rejoined the room.
[8:22pm] Dado1: Thank you guys! I hope the file size limit is over soon, so that I can write a FUSE adapter and use GAE as a metadata-rich, distributed file system!
[8:23pm] jeffr_: my other question is that I am currently visiting india and i noticed that my site is pinging at ~150 ms, while google is about 30ms
[8:23pm] jeffr_: are there plans to improve GAE cdn?
[8:24pm] marzia_google: i think we are sensitive to serving content well at any geographical location, and improving this is definitely something we are working on
[8:26pm] jeffr_: excellent
[8:26pm] jeffr_: would a trace route or anything be helpful?
[8:26pm] marzia_google: i think issue 531 is to what you are referring?
[8:26pm] marzia_google: and it's definitely on the teams radar
[8:27pm] pranny left the chat room. (Read error: 104 (Connection reset by peer))
[8:27pm] marzia_google: it seems a pretty complete description, but we'll definitely ping the issue for more info if needed
[8:31pm] jeffr_: this is more of a general question - why is it that HTTP connections seem to take a while to get "warmed up"? like they start out slow but tend to get faster until they hit a peak
[8:31pm] brian_skinner left the chat room. (Read error: 110 (Connection timed out))
[8:31pm] marzia_google: if you are serving enough qps we do actually fire up multiple python interpreters for your app
[8:32pm] marzia_google: the best explanation of this is in ken ashcraft's talk
[8:32pm] marzia_google: (finding link...
[8:32pm] danielobrien: It could also be module loading, if your app is loaded infrequently.
[8:32pm] marzia_google: http://sites.google.com/site/io/best-practices---building-a-production-quality-application-on-google-app-engine
[8:34pm] jeffr left the chat room. (Read error: 110 (Connection timed out))
[8:36pm] dan_google left the chat room.
[8:36pm] marzia_google: doing lots of plugging tonight, so as usual i'd plug watching basically every app engine google i/o talk
[8:36pm] marzia_google: (probably other i/o talks too)
[8:36pm] marzia_google: we say it a lot on the forum, but really it's always worth repeating
[8:36pm] jeffr_: this is more of a general HTTP question
[8:37pm] jeffr_: like why does a download start at 10k/sec and then gradually reach 300k/sec
[8:37pm] jeffr_: instead of immediately starting at 300k/sec
[8:37pm] moraes: i can't point *.domain.com to ghs.google.com?
[8:39pm] marzia_google: ah well as daniel said it depends on the previous amount of traffic your app has been serving
[8:39pm] marzia_google: moraes: you can map an app engine app to any apps subdomain not already taken
[8:40pm] marzia_google: is there a specific issue you are having with subdomain mapping
[8:40pm] marzia_google: if your python interpreter has gone cold
[8:41pm] troy_google: jeffr_: that is TCP at work
[8:41pm] jeffr_: is it better to have one large image, or several smaller images
[8:41pm] moraes: no, actually... i just discovered issue #113... i was planning to handle dynamic subdomains in my app... seems that i'll have to go to plan b
[8:42pm] troy_google: it starts off with sending small amount of data and increases it until it finds the right speed for the connection to the other host
[8:42pm] marzia_google: oh yes, currently we don't support dynamic subdomains
[8:42pm] jeffr_: troy_google: that is pretty excellent
[8:43pm] troy_google: jeffr_: with HTTP 1.1 and persistent connections, you should be able to avoid restarting that TCP ramp up, since it should use the channel that is already setup
[8:44pm] jeffr_: nice
[8:47pm] marzia_google: well, this is where i depart
[8:47pm] marzia_google: good night (/late night/morning/afternoon)
[7:02pm] moraes: "Enter a valid Austrian Social Security Number in XXXX XXXXXX format." -> locales are curious
[7:02pm] cresloyd joined the chat room.
[7:02pm] danielobrien: This is intended as a pretty informal session, so just ask questions and hopefully we'll catch all of them.
[7:03pm] marzia_google: i'll take the ToS question, as long as it's understood that IANAL
[7:03pm] brian_skinner:
[7:03pm] brian_skinner: The terms say "You must provide legally adequate privacy notice and protection for those users", and "You agree to set up a process to respond to notices of alleged infringement that comply with the United States' Digital Millennium Copyright Act"
[7:03pm] Dado1: IANAL sounds like a bad word to me
[7:03pm] brian_skinner: http://code.google.com/appengine/terms.html
[7:04pm] marzia_google: IANAL = i am not a lawyer
[7:04pm] brian_skinner: Is there a simple example anywhere that shows what I need to do to make sure my website complies with the terms? Like, in the App Gallery, is there an example app with a minimally conforming privacy notice and DMCA process notice?
[7:04pm] Dado1:
[7:04pm] danielobrien: peterr: It depends on the type of support you're looking for. There will be some additional support for billing-related issues.
[7:05pm] marzia_google: oh, this is definitely a question for a lawyer
[7:05pm] peterr: ok. any comment on the scary stories of people getting locked out of their google accounts? should I create a seperate account for my app engine work?
[7:05pm] brian_skinner: okay, thanks marzia_google -- thought I'd try here
[7:06pm] marzia_google: so, loosing access to google account does not affect how your app would run
[7:06pm] danielobrien: peterr: We *are* constantly trying new things though. Like these chat sessions.
[7:06pm] marzia_google: it would affect your personal ability to log in to any service that uses google accounts, but perhaps have multiple admins on your app?
[7:06pm] pranny: What is the difference between keys and IDs. As far as my perception goes, keys are manually assigned, while IDs are assigned automatically if we don't specify a key value. I fear I might be wrong.
[7:06pm] Dado1: Will GAE limitations/quotas on file size and request timeout ever be lifted/relaxed for paying customers to make them able to design applications that handles sizable binary files (1-10Mb) on average?
[7:07pm] dan_google: pranny: You got it.
[7:07pm] jcgregorio joined the chat room.
[7:07pm] Dado1: pranny: key_names are manually assigned, ID are automatically assigned... key_names or ID then becomes part of the key
[7:07pm] jcgregorio: hello, sorry for being late
[7:07pm] pranny: Okay, I got it
[7:08pm] marzia_google: keys also contain information about the ancestor path
[7:08pm] dan_google: pranny: More specifically, the "key" is what uniquely identifies the entity. A key can have either an app-assigned key_name or a system-assigned ID.
[7:08pm] marzia_google: so you can generate a key given the ancestor
[7:08pm] marzia_google: so for instance key.from_path()
[7:08pm] marzia_google: http://code.google.com/appengine/docs/datastore/keyclass.html
[7:09pm] pranny: Okay, Thanks
[7:09pm] danielobrien: Dado1: I think this overlaps with your previous question? File sizes being relaxed are on our roadmap for within the next two quarters, and when implemented, would affect both paying and non-paying users.
[7:09pm] Dado1: daniel: but that is intrinsically tied to the request/response timeout
[7:09pm] danielobrien: Dado1: The quotas relevant to billing are those on the "Understanding Quotas" page. Others, like request timeouts and file sizes, are more technical limitations.
[7:10pm] ribrdb joined the chat room.
[7:10pm] Dado1: daniel: when I saw that google positioned appengine storage charges in line with Amazon S3 I thought I could you use GAE as a supercharged S3
[7:11pm] darren__: I am concerned about datastore backup. Will there be an solution provided soon or will we have to continue with our own methods? Also, will there be be any google service for datastore work such as data rollback etc?
[7:11pm] Dado1: and that I could store as much as I wanted (per file and per app) by paying for it
[7:11pm] marzia_google: darren__ bulk upload and download are on the roadmap for the next two quarters
[7:11pm] darren__: cool
[7:11pm] Dado1: daniel: but I keep coming across a phantomatic "Python variable size limit of 1Mb" which I still don't quite understand!!!
[7:12pm] pr3d4t0r: marzia_google: . o O o .
[7:12pm] marzia_google: for longer term things such as data rollback, that is nice to have, but not a current priority
[7:12pm] pr3d4t0r: marzia_google: Howdy
[7:12pm] marzia_google: hello
[7:12pm] pr3d4t0r: marzia_google: To what do we owe the pleasure?
[7:12pm] marzia_google: oh it's app engine chat time
[7:12pm] • pr3d4t0r checks the calendar.
[7:13pm] pr3d4t0r: marzia_google:
[7:13pm] danielobrien: Dado1: Understood. Dealing with large files at all requires relaxing those limits, so I suspect it's part of the goal in increasing the actual file size limits.
[7:13pm] • pr3d4t0r STFU and listens.
[7:13pm] marzia_google: ah well we welcome all questions
[7:13pm] marzia_google: so listening is nice, but participation is also great
[7:13pm] marzia_google:
[7:13pm] danielobrien: That isn't to say we'll necessarily remove the limits of urlfetch, datastore operations, python computation, etc.
[7:14pm] troy_google joined the chat room.
[7:14pm] marzia_google: i think the thing to realize is that the http response limit will still exist, but there will also be support for longer running requests, large file uploads
[7:14pm] darren__: will the docs be improved, with more examples. I am getting there with it but its bad for my head!
[7:14pm] marzia_google: so there will be a bit of both
[7:15pm] dan_google: darren__: docs are steadily being improved
[7:15pm] Dado1: marzia/daniel: ok, good
[7:15pm] dan_google: darren__: we hear the need for more examples loud and clear
[7:15pm] jcgregorio: yes, we've got more articles in the pipeline
[7:15pm] dan_google: darren__: though we're also busy documenting new features.
[7:16pm] darren__: that would be great. Thanks guys
[7:16pm] • pr3d4t0r is busy working on that.
[7:16pm] minishark: Are there any plans to add more Google services to the Google Data APIs?
[7:16pm] jcgregorio: darren__: anything in particular you want to see expounded upon?
[7:16pm] danielobrien: minishark: It's already possible to access them using the Google Data python libraries.
[7:16pm] Dado1: I posted a ticket a while back regarding adding a Unique=True/False arg to the property constructor/declaration, like it is done in Djiango models... any thought on that? Any solution as to how to ensure a property value is unique across a datastore (email address for example)???
[7:17pm] darren__: all the datastore section especially
[7:18pm] peterr: can you add a 52 point bold flashing headline somewhere that says "GQL is not SQL"?
[7:18pm] ribrdb: Dado1: the best way to ensure uniqueness is to use the property as a key_name
[7:18pm] brett_google joined the chat room.
[7:19pm] dan_google: <blink style="font-size: 52px">GQL is not SQL.</blink>
[7:19pm] marzia_google: peterr: flashing and i'm thinkng maybe some kind of song to go with it
[7:19pm] Dado1: ribrdb: that works if the value is immutable... but for say, a user email address that can change that doesn't work!!!
[7:19pm] marzia_google: perhaps eye of the tiger..
[7:19pm] darren__:
[7:19pm] brett_google: heyo
[7:19pm] jcgregorio: minishark: there's an ongoing effort to add Google Data APIs to new products, but obviously I can't comment on which ones are being worked on, or any timing like that
[7:20pm] jcgregorio: minishark: (I worked with the Google Data APIs group before joining the App Engine team)
[7:20pm] jcgregorio: hey brett_google
[7:20pm] brett_google: hey joe
[7:20pm] marzia_google: we've had several more googlers join us since introductions
[7:20pm] danielobrien: Dado1: At present, outside of using key_name, the only option is a manual uniqueness check.
[7:21pm] ironfroggy_ left the chat room. ("http://www.mibbit.com ajax IRC Client")
[7:21pm] brett_google: sorry for being late
[7:21pm] jcgregorio: jcgregorio == Joe Gregorio, Developer Advocate for App Engine
[7:21pm] minishark: I was mostly just interested in the Google Analytics API, which I know is in private beta right now. Hopefully it'll be rolled out to everyone soon.
[7:21pm] marzia_google: i would say you were fashionable, brett
[7:21pm] Dado1: daniel: I tried that, but not being able to query inside a transaction doesn't ensure uniqueness, even if a manual check is done
[7:21pm] jcgregorio: and only a couple minutes later than me
[7:22pm] ribrdb: Dado1: you could probably make it work by creating a new entity when they change the email address.
[7:23pm] brett_google:
[7:23pm] Dado1: ribrdb: sure, but I will then have to update all references to it... and it would also screw up the entity groups etc
[7:24pm] Dado1: I think a UNIQUE index options would do, if in any way possible
[7:24pm] minishark: What are your plans for supporting Python 3.0 when it comes out?
[7:25pm] minishark: bc it's not backwards compatible
[7:25pm] brett_google: minishark: guido has said before that we're going to consider it a totally separate language
[7:25pm] brett_google: because of that issue, among other things
[7:25pm] danielobrien: When we introduce backward-incompatible changes we'd also require a version change in app.yaml.
[7:26pm] brett_google: in terms of an api version, right
[7:26pm] brett_google: but in this case it would need to be a separate runtime, because the language is fundamentally not backwards compatible
[7:26pm] danielobrien: Yep, makes sense.
[7:26pm] r0ver left the chat room. ("Leaving.")
[7:27pm] peterr: oh i see. the "new language" we're getting is really just python 3.0!
[7:27pm] Dado1: Ruby please!!!
[7:27pm] brett_google: haha
[7:27pm] marzia_google: FORTRAN77 please
[7:27pm] brett_google: oh i don't know we'll see
[7:27pm] danielobrien: No Cobol?
[7:27pm] Dado1: Lisp
[7:27pm] • jcgregorio secretly wants Forth
[7:27pm] moraes: smalltalk, please
[7:28pm] dan_google: 6502 assembly please
[7:28pm] Dado1: erlang
[7:28pm] minishark: I want Logo so I can make that little turtle draw pictures
[7:28pm] ribrdb: Dado1: In my app I do something like this by having a separate entity that I only use for checking uniqueness. I still store the data in a regular property too. Something like that might work for you.
[7:28pm] r0ver joined the chat room.
[7:28pm] darren__: why are these chats so late? not great for us in Europe!
[7:28pm] marzia_google: we alternate
[7:28pm] dan_google: minishark: http://www.cologo-lang.org/
[7:28pm] peterr: they alternate times darren
[7:28pm] marzia_google: mornings and evenings
[7:29pm] marzia_google: 1st weds of the month 7-8
[7:29pm] marzia_google: 3rd 9-10am
[7:29pm] marzia_google: all pacific time
[7:29pm] marzia_google: that would be 3rd weds of the month
[7:29pm] minishark: haha that's awesome. really takes me back to elementary school!
[7:29pm] darren__: righto - nice
[7:30pm] brett_google: marzia: so did you already ask if anyone's got an app they want to show off?
[7:30pm] marzia_google: oh we haven't
[7:30pm] marzia_google: but
[7:30pm] marzia_google: that's a great question
[7:30pm] marzia_google: which you just asked
[7:30pm] Dado1: ribrdb: sure, but once you have check uniqueness with that special entity, how do you know somebody is not adding the same value in a standard entity while you are transferring it from the special entity to the one holding the value in a standard property???
[7:30pm] jcgregorio: Dado1: are you trying to protect a single property so it can never be changed to match another value already in the store?
[7:31pm] Dado1: jcgregorio: yes, both at create and update time
[7:31pm] jcgregorio: and you'd also like to do exact matches on that property in queries?
[7:32pm] Dado1: jcgregorio: that's already possible... what I would like is to have a UNIQUE index of some sort
[7:33pm] Dado1: jcgregorio: sure, something like Model.get_or_insert_by_uniquepropertyname() would be nice too!
[7:34pm] Dado1: jcgregorio: like dynamic finders in Rails
[7:34pm] Dado1: jcgregorio: but I mostly worried about data integrity
[7:34pm] jcgregorio: ok, not familiar with dynamic finders in Rails
[7:34pm] Dado1: and duplication
[7:35pm] darren__ left the chat room.
[7:36pm] marzia_google: so, how would get_or_insert_by_uniquepropertyname differ from get_or_insert_by_key_name?
[7:36pm] marzia_google: in your design?
[7:36pm] jcgregorio: right, but unless they're in the same entity group you can't enforce what happens in other entities
[7:36pm] Dado1: marzia: key_name is immutable after creation, emai addresses aren't
[7:37pm] marzia_google: right so, you want a uniquepropertyname that is changeable?
[7:37pm] marzia_google: but still unique?
[7:37pm] brett_google: so yeah you'd need an intermediary entity
[7:37pm] Dado1: marzia: you got it!
[7:38pm] brett_google: ah just read the earlier chat
[7:38pm] brett_google: i understand the issue
[7:39pm] Dado1: marzia: http://docs.djangoproject.com/en/dev/topics/db/models/#field-options
[7:40pm] Dado1: marzia: something like the Djiango field property unique would be very welcomed
[7:41pm] brett_google: i think that's probably possible within a single entity kind
[7:41pm] brett_google: fundamentally with bigtable
[7:41pm] brett_google: doing it cross-kind would be more difficult
[7:41pm] Dado1: brett_google: I only need it within a single entity kind... like in djiango, unique only applies within a single table
[7:42pm] brett_google: yeah it's a cool idea
[7:42pm] brett_google: theoretically you could do it for any index in the index.yaml file
[7:42pm] Dado1: brett_google: any orm I've seen out there supports a unique modifier for properties
[7:43pm] brett_google: so you could do uniqueness on a composite index
[7:43pm] Dado1: brett_google: exactly, you're reading my mind... composite unique key would also be nice
[7:43pm] brett_google: sounds like a great issue to open
[7:43pm] danielobrien: Yep, we already have it in the issue tracker. It's fairly popular, going by stars.
[7:43pm] Dado1: I opened it very soon after gae launched
[7:44pm] brett_google: cool
[7:44pm] danielobrien: In case it hasn't been posted already: http://code.google.com/p/googleappengine/issues/detail?id=178
[7:45pm] Dado1: dado is short for edoardo
[7:45pm] marzia_google: i think it's an interesting feature request, i think it touches on a theme we talked a lot about in the first chat which is prioritizing requests
[7:45pm] Dado1: dynamic generated methods like Model.get_by_uniquepropertyname would then be easy to do
[7:46pm] Dado1: like User.get_by_email
[7:46pm] Dado1: I am not talking about the google appengine users.User... but a custom one
[7:47pm] marzia_google: sure, i think with all feature requests, if i may quote myself from last time quoting ryan
[7:47pm] marzia_google: 'we love them all equally, but we have to work on one (or a few) at a time'
[7:47pm] marzia_google: so the team is also working on the features like ability to pay for more quota
[7:47pm] marzia_google: and large file uploads
[7:47pm] marzia_google: offline processing
[7:47pm] marzia_google: system stability
[7:47pm] marzia_google: etc
[7:48pm] Dado1: marzia: I just thought that this is such a common thing in databases that google big table already implements it
[7:49pm] Dado1: large file uploads and offline processing are a MUST!!! but unique indexes I thought would have been already done in bigtable by google for their on sake
[7:50pm] peterr: do the appengine folks follow EC2 and other cloud projects out there closely, or do you mostly just worry about appengine?
[7:51pm] Dado1: peterr: windows azure seems more similar to GAE than EC2/S3
[7:51pm] marzia_google: i think that the key is to decouple traditional relational databases and the datastore in your mind
[7:51pm] brett_google: dado1: bigtable's nothing but unique indexes, since it just maps row keys to value columns; this comes more into play with how bigtable works together with the Datastore API; you can watch ryan's talk from Google I/O for more details on the way the composite indexes work
[7:52pm] moraes left the chat room. (Read error: 104 (Connection reset by peer))
[7:52pm] jeffr joined the chat room.
[7:52pm] troy_google: I follow them in my personal time closely out of general interest in the field
[7:52pm] Dado1: brett_google: that's exactly why I thought exposing it in the datastore api would require much effort... but I am probably very wrong since I am a neuroscientist during the day, and the programmer just for few hours during the night
[7:53pm] Dado1: brett_google: I meant WOULDN'T require much effort
[7:53pm] marzia_google: yeah i was going to say i think that all of us on the app engine team are interested and excited by all the different things going on in this field
[7:53pm] moraes joined the chat room.
[7:54pm] brett_google: dado1: it sounds like a good fit and is clearly useful
[7:54pm] marzia_google: i think also when it comes to adding features and things, the key to remember is that what is maybe a conceptual easy change still takes lots of time to implement
[7:54pm] marzia_google: write design test
[7:54pm] marzia_google: etc
[7:55pm] Dado1: marzia: sure!!! on that issue... how big is the GAE team... in term of developers?
[7:56pm] jeffr: any progress on the GAE latency issues when using a non appspot domain?
[7:57pm] marzia_google: i think that number is hard to guage really accurately, because there are app engine developers, contributors, and contributors to the services like big table app engine uses
[7:58pm] Dado1: marzia: just GAE developers
[7:58pm] Dado1: marzia: more or less
[7:59pm] Dado1: one more thing... any progress on a real fulltext search api (using the full google power)???
[8:00pm] Dado1: I mean full text search of model properties
[8:00pm] binarybandit left the chat room. ("Later")
[8:00pm] marzia_google: officially we don't generally give out specific staffing numbers, but i can say that it's def bigger than dan_google, brett_google, troy_google, danobrien, ribrdb and jcgregorio that are here tonight
[8:00pm] marzia_google: so
[8:00pm] marzia_google:
[8:00pm] Dado1: got it
[8:01pm] marzia_google: ah that's something that we are definitely looking in to as well
[8:01pm] marzia_google: fulltext search
[8:01pm] danielobrien: jeffr: Not that I'm aware of. It isn't something we've forgotten about though.
[8:01pm] Dado1: it would be nice in the gae group to know when we are talking to gae dev team members... with an icon or something
[8:01pm] jeffr: sweet
[8:01pm] marzia_google: yeah, i'm not sure that irc supports that
[8:02pm] Dado1: marzia: no, I mean in the google group... amazon does it in its dev forums
[8:02pm] danielobrien: We could bug one of the ops to have us all voiced for next time, possibly? Or just adopt the _google suffix.
[8:02pm] Dado1: the suffix would work!
[8:02pm] marzia_google: oh in the forums, yes the @google email address is subtle
[8:02pm] marzia_google: and the problem with adding something to your profiel in groups is that if you post by email (like me) it doesn't actually work
[8:03pm] danielobrien: For the forums, some of us add "(Google)" to our names. Certain Google Groups also support more complex badging.
[8:03pm] danielobrien: It means a fairly major change to the groups though.
[8:03pm] marzia_google: yeah, the (Google) thing only works if you post through the groups UI
[8:03pm] Dado1: I think a suffix like gae_team would work well
[8:04pm] marzia_google: perhaps we could also post an introduction to known google posters
[8:04pm] Dado1: yes, perhaps in a (hopefully) upcoming FAQ
[8:04pm] danielobrien: I know we want to avoid cluttering the main groups page, but it may also fit there.
[8:05pm] danielobrien: Oh, and since it's past 8:00 the chat is officially over. I suspect a few of us will still be around though.
[8:06pm] minishark left the chat room. ("Leaving")
[8:06pm] Dado1: it would be nice, if allowed by the developers, to look at the source of appengine apps
[8:06pm] danielobrien: Your own apps, or other people's?
[8:06pm] Dado1: as an option for the app
[8:06pm] peterr: thanks to all the gae folks for being available
[8:07pm] peterr left the chat room.
[8:07pm] moraes: oooh. just found http://code.google.com/p/googleappengine/issues/detail?id=113. i didn't know that. my app is totally expecting to deal with wilcards.
[8:07pm] marzia_google: thanks everyone for coming
[8:07pm] Dado1: other people
[8:07pm] brett_google: dado1: well there's this one: http://shell.appspot.com/
[8:07pm] pranny: Thanks GAE team
[8:07pm] brett_google: and it has the link on the upper right
[8:07pm] danielobrien: Source privacy is a big concern for a lot of people, so it would definitely need to be optional.
[8:07pm] brett_google: not too hard to do it yourself like that; but it'd be cool if it were automatic
[8:07pm] Dado1: brett: thanx
[8:07pm] Dado1: daniel: definitively optional
[8:07pm] marzia_google: and it would be a good time to plug version control and open source software development
[8:08pm] marzia_google: as good existing solutions
[8:08pm] danielobrien: Since I also work on project hosting I'm inclined to point people to that, which has its own source browsing.
[8:09pm] Dado1: it would nice if, on a opt-in basis, a gae app would be sync'ed with a google code project
[8:10pm] Dado1: for example when using appcfg update
[8:10pm] marzia_google: yes, that would be totally cool
[8:10pm] danielobrien: Yep, that's another popular feature request. Better source control integration in general on top of that.
[8:11pm] Dado1: please add git support to google code
[8:11pm] marzia_google: totally off topic, but if you have google apps, you can add rietveld using apps labs
[8:11pm] marzia_google: which is generally pretty awesome
[8:11pm] marzia_google: or rather 'google code reviews'
[8:11pm] marzia_google: http://www.google.com/enterprise/marketplace/viewListing?productListingId=5143210+12982233047309328439
[8:12pm] danielobrien: Yep, git's another popular request. You're probably getting tired of me saying that without giving a position.
[8:13pm] Dado1: how about a polling system to prioritize feature requests? the star system is annoying... given that you get all those +1 emails
[8:14pm] marzia_google: well people shouldn't +1 and star
[8:14pm] marzia_google: ...
[8:14pm] marzia_google: i think starring should not email everyone on this list
[8:14pm] brian_skinner_ joined the chat room.
[8:14pm] Dado1: marzia: you're right... but people still voted almost 50% for a republican after 8 years of Bush
[8:15pm] danielobrien: Yeah, that's on the project hosting team's feature request list. It's another one of those prioritization issues though.
[8:15pm] brett_google: alright time to go; have a good one everybody
[8:15pm] jeffr_ joined the chat room.
[8:15pm] brett_google left the chat room. ("peaceout")
[8:15pm] danielobrien: Perhaps refine down to a shorter list and use Google Moderator or something?
[8:15pm] Dado1: danielobrien: exactly
[8:16pm] brian_skinner_ left the chat room. (Client Quit)
[8:16pm] danielobrien: Actually, with project hosting's recently added support for embedded gadgets there may be a solution there.
[8:17pm] danielobrien: I should probably get off the project hosting tangent though.
[8:18pm] jeffr_: i notice that when i deploy my app, there are a few seconds where my app is inaccessible - what is the best way to deploy to avoid this?
[8:18pm] marzia_google: versioning of your app
[8:18pm] jeffr_: is there a way to automate this?
[8:18pm] jeffr_: i think i am on my 1000th revision of my app
[8:18pm] marzia_google: actually i would suggest also, if you are adding new indexes, run update_indexes before uploading your app
[8:19pm] marzia_google: oh well, the only way currently is to manually update hte version in app.yaml
[8:19pm] danielobrien: I suspect you could just swap back and forth between live versions?
[8:19pm] marzia_google: i'm sure clever people could write a great build script to take care of that for you
[8:19pm] Dado1: would the suggested workflow be vacuum + update indexes, then update app?
[8:19pm] jeffr_: it would be awesome if i could just press one button
[8:19pm] jeffr_: like i do now
[8:20pm] marzia_google: there is really no need to vacuum indexes
[8:20pm] marzia_google: unless you are getting close to 100 and not using one any more
[8:20pm] Dado1: marzia: ok, thanx
[8:20pm] marzia_google: well you can press a button to deploy, but not to edit the app.yaml
[8:21pm] troy_google: jeffr: we are aware of that problem and I believe we do have a solution to make it better ... however daniel and marzia's solution is the preferred method for the time being
[8:21pm] You left the chat by being disconnected from the server.
[8:22pm] You rejoined the room.
[8:22pm] Dado1: Thank you guys! I hope the file size limit is over soon, so that I can write a FUSE adapter and use GAE as a metadata-rich, distributed file system!
[8:23pm] jeffr_: my other question is that I am currently visiting india and i noticed that my site is pinging at ~150 ms, while google is about 30ms
[8:23pm] jeffr_: are there plans to improve GAE cdn?
[8:24pm] marzia_google: i think we are sensitive to serving content well at any geographical location, and improving this is definitely something we are working on
[8:26pm] jeffr_: excellent
[8:26pm] jeffr_: would a trace route or anything be helpful?
[8:26pm] marzia_google: i think issue 531 is to what you are referring?
[8:26pm] marzia_google: and it's definitely on the teams radar
[8:27pm] pranny left the chat room. (Read error: 104 (Connection reset by peer))
[8:27pm] marzia_google: it seems a pretty complete description, but we'll definitely ping the issue for more info if needed
[8:31pm] jeffr_: this is more of a general question - why is it that HTTP connections seem to take a while to get "warmed up"? like they start out slow but tend to get faster until they hit a peak
[8:31pm] brian_skinner left the chat room. (Read error: 110 (Connection timed out))
[8:31pm] marzia_google: if you are serving enough qps we do actually fire up multiple python interpreters for your app
[8:32pm] marzia_google: the best explanation of this is in ken ashcraft's talk
[8:32pm] marzia_google: (finding link...
[8:32pm] danielobrien: It could also be module loading, if your app is loaded infrequently.
[8:32pm] marzia_google: http://sites.google.com/site/io/best-practices---building-a-production-quality-application-on-google-app-engine
[8:34pm] jeffr left the chat room. (Read error: 110 (Connection timed out))
[8:36pm] dan_google left the chat room.
[8:36pm] marzia_google: doing lots of plugging tonight, so as usual i'd plug watching basically every app engine google i/o talk
[8:36pm] marzia_google: (probably other i/o talks too)
[8:36pm] marzia_google: we say it a lot on the forum, but really it's always worth repeating
[8:36pm] jeffr_: this is more of a general HTTP question
[8:37pm] jeffr_: like why does a download start at 10k/sec and then gradually reach 300k/sec
[8:37pm] jeffr_: instead of immediately starting at 300k/sec
[8:37pm] moraes: i can't point *.domain.com to ghs.google.com?
[8:39pm] marzia_google: ah well as daniel said it depends on the previous amount of traffic your app has been serving
[8:39pm] marzia_google: moraes: you can map an app engine app to any apps subdomain not already taken
[8:40pm] marzia_google: is there a specific issue you are having with subdomain mapping
[8:40pm] marzia_google: if your python interpreter has gone cold
[8:41pm] troy_google: jeffr_: that is TCP at work
[8:41pm] jeffr_: is it better to have one large image, or several smaller images
[8:41pm] moraes: no, actually... i just discovered issue #113... i was planning to handle dynamic subdomains in my app... seems that i'll have to go to plan b
[8:42pm] troy_google: it starts off with sending small amount of data and increases it until it finds the right speed for the connection to the other host
[8:42pm] marzia_google: oh yes, currently we don't support dynamic subdomains
[8:42pm] jeffr_: troy_google: that is pretty excellent
[8:43pm] troy_google: jeffr_: with HTTP 1.1 and persistent connections, you should be able to avoid restarting that TCP ramp up, since it should use the channel that is already setup
[8:44pm] jeffr_: nice
[8:47pm] marzia_google: well, this is where i depart
[8:47pm] marzia_google: good night (/late night/morning/afternoon)
Reply all
Reply to author
Forward
0 new messages