The high-level summary and complete transcript of the February 3rd edition of the IRC office hours is pasted below. Please join us on the first and third Wednesday of every month in the #appengine channel on irc.freenode.net. On the first Wednesday, we meet in the channel from 7:00-8:00 p.m. PST (evening hours), and on the third Wednesday, we're available from 9:00-10:00 a.m. PST (morning hours).
- Jason --SUMMARY----------------------------------------------------------- - Most of the chat took place in another IRC channel because the usual channel was closed to unregistered users. As a result, the chat started later than usual. The next chats should take place in the regular channel: #appengine on irc.freenode.net. If you can't post, please register your nick by following the instructions at http://freenode.net/faq.shtml#registering. [7:12-7:15] - Discussion on datastore cursors, a premiere feature of the 1.3.1 release, which enable developers to work with result sets larger than 1,000. [7:16-7:22] - Q: As a developer of an app allowing users to upload content, what level of policing should I do to make sure the uploaded content does not violate App Engine's terms of service? A: You should not encourage or openly permit content in violation of the terms of service. This means that should you spot such content, you take care to remove it, and you also take care to do the same if a member of the App Engine team contacts you about any violations. For this type of violation, we will reach out to you first to give you an opportunity to remove the content before taking your application offline. [7:22-7:25, 7:27] - Q: Are there any plans to allow for larger URL fetch requests, up to 5+ MB? A: No plans at present, but please star this issue if you're interested: http://code.google.com/p/googleappengine/issues/detail?id=2735. It's possible that we could implement this feature similar to the way we increased the maximum image data size that could be operated on via the image service functions: by allowing blob keys to be passed rather than the raw data directly. Another idea is making the URL fetch service work with a callback, similar to blobstore. [7:25-7:29, 7:31-7:33, 7:39] - If multiple writes occur in a single transaction, they must be processed sequentially. This is because a transaction can only apply to entities in the same entity group, and an entity group cannot be updated while another update is taking place. Use entity groups only when necessary -- try to keep them as small as possible to maximize write throughput. [7:30-7:31, 7:33-7:34] - Follow-up on index inconsistency issues (issue 2481): we are taking this issue very seriously, and have devoted many hours so far tracking down the cause. For most apps that we have identified as being affected, we have manually corrected the problem indexes, but we're still working on the root cause. The team is making substantial progress and the timeline for a fix is "weeks" and not "months". If you continue to see this problem, please add a comment to http://code.google.com/p/googleappengine/issues/detail?id=2481. [7:35, 7:38-7:40] - Discussion on google.appengine.tools.bulkloader.IncrementId implementation, whether it's hardened enough to prevent conflicts of auto-generated IDs, and whether a better implementation is coming. [7:42, 7:46] - Discussion on authentication using the Google Accounts service, how it's implemented and security mechanisms in place. [7:44-7:48] - Q: What are transactional tasks? A: Simply put, tasks that are added to queues when there is an active datastore transaction will be automatically enlisted in the datastore transaction so most of the time you won't actually need to get ahold of the active com.google.appengine.api.datastore.Transaction. [7:49, 7:53] - Discussion on pre-releases and need for a production sandbox where new back-ends can be released and tested without (potentially) breaking production apps. [7:54-7:55, 7:57] - Cool app which compares the performance of the different Java datastore APIs: http://gaejava.appspot.com/. The low-level API outperforms JDO/JPA, even though JDO and JPA are technically using the same underlying implementation as the low-level API, likely due to the ORM-layer overhead. [7:58-8:04, 8:10-8:11] - Poll: For developer-to-developer support, do you prefer Google Groups or Stack Overflow? [8:05-8:11] --FULL TRANSCRIPT----------------------------------------------------------- [7:11pm] apijason_google: Ha ha. Anyway, we'll be here for the next 50 minutes at least. Ikai and I are here, Wesley is coming soon. Sorry for the technical difficulties. [7:12pm] _tmatsuo: perhaps you can register your nick on the net. [7:12pm] _tmatsuo: *on freenode.net [7:13pm] apijason_google: Yeah, after today's incident, we just might do that. [7:13pm] ikai_google: registered, no dice [7:13pm] ikai_google: I still can't post in the other forum [7:13pm] ikai_google: err channel [7:13pm] lambo4jos: hello everyone [7:13pm] ikai_google: oh wait [7:13pm] moraes: i'll ask nickjohnson to give power to some of us [7:13pm] ikai_google: gotta click some email link [7:13pm] Wooble: page nickjohnson, wake him up. [7:13pm] ikai_google: hah, nick doesn't carry a pager anymore [7:14pm] Wesley_Google: Greetings everyone! Congrats on finding the new room. I couldn't post in the original room either. We'll get a hold of nickjohnson one way or another. [7:14pm] ikai_google: http://freenode.net/faq.shtml#registering [7:15pm] lambo4jos: do all scheduled chats happen in this room? [7:15pm] ikai_google: they should happen in appengine [7:15pm] ikai_google: BOOM. One question answered [7:15pm] ikai_google: [7:15pm] Wooble: no, freenode suffered a spam attack and lots of channels are +R now. [7:15pm] lambo4jos: haha! thats what i was assuming. is this just temporary? [7:15pm] moraes: lambo4jos, no. #apoengine is registered members only and the google people is not registered [7:15pm] ikai_google: yeah [7:15pm] ikai_google: I registered [7:15pm] moraes: guys, do you know about the new cursors? [7:15pm] lambo4jos: got it [7:15pm] ikai_google: so I am in the other room now [7:15pm] ikai_google: yeah, the 1.3.1 stuff [7:15pm] ikai_google: pretty exciting [7:15pm] moraes: lambo4jos, because of recent spam waves [7:15pm] ikai_google: the docs aren't online yet [7:16pm] ikai_google: but you can look at the docs that come with the SDK [7:16pm] moraes: yes, i tried them. like, months ago [7:16pm] ikai_google: in the case of python you ... unfortunately need to grep [7:16pm] moraes: then agian a couple of hours ago [7:16pm] ikai_google: they shouldn't work in prod yet on a deployed app [7:16pm] lambo4jos: what are cursors? [7:16pm] Wooble: moraes has been excited about cursors since they first appeared in the roadmap. [7:16pm] moraes: and i got it working. [7:16pm] ikai_google: cursors are a way for you to work with datasets larger than 1000 [7:16pm] ikai_google: they're coming in 1.3.1 [7:16pm] ikai_google: you get preview access in our prerelease SDK [7:17pm] moraes: so. what when you reach last set of results. it still returns a valid cursor. can you detect that it is the last set? [7:17pm] lambo4jos: ooh! where can i get a preview release sdk? [7:17pm] jason_google: Doh [7:17pm] jason_google: OK, I think I'm set. [7:18pm] Wesley_Google: download here: http://bit.ly/cmqXGT [7:18pm] enigmus: ikai_google: Using a cursor, do the first results get retrieved as well from the datastore? Is there a performance difference wrt offset? [7:18pm] lambo4jos: thanks. checking it out now. be back in a sec [7:18pm] _tmatsuo: looking through the source, Query class has a lovely cursor() method now. presumably we can serialize a half-way queries with this method. [7:19pm] _tmatsuo: for later use [7:20pm] ikai_google: enigmus: I'm not completely sure about the exact characteristics of cursors at the moment, so I couldn't tell you. As far as performance goes, no, there shouldn't be a difference [7:20pm] ikai_google: I have a bit of an admission here, I'm no expert on cursors yet [7:21pm] ikai_google: I've seen some early docs but not the final ones, but if you have any questions I can't answer, feel free to ask on the mailing list [7:21pm] jason_google: enigmus: I need to ramp up on it myself, but I believe you should only retrieve results from the cursor, so it should have better performance than using offset. [7:21pm] ikai_google: and I'll take some time to research and get you guys some answers [7:21pm] moraes: _tmatsuo, http://paste.pocoo.org/show/173706/ [7:21pm] ikai_google: enigmus: what I mean is, the further you are in the dataset it shouldn't take longer [7:22pm] Wooble: I have a TOS question. Let's say I'm building a photosharing site; just how much policing of user-contributed content am I expected to do? Is it enough to have my own terms of use forbid the same stuff the Google ones do, and take action if I'm notified of violations, or am I expected to view every uploaded photo? [7:22pm] enigmus: jason_google: That would indeed make sense. offset is very limiting that way. [7:22pm] lambo4jos: what is the new transactional task creation for python? [7:22pm] moraes: you guys know why cursors return a valid cursor when you are in the end of the dataset? is this expected? [7:23pm] ikai_google: Wooble: You should be responsible for your content, since we will not be reviewing it [7:23pm] jason_google: Wooble: I am not a lawyer, but your sites should not explicitly permit content that is not permitted in the App Engine TOS and you should take measures to remove it if it's reported to you. [7:23pm] jason_google: With content violations that we spot, we'll generally report it to you first before taking your app down. [7:23pm] ikai_google: Wooble: But if we receive reports that you have violating content, yes, we can shut you down. Though in most cases we'll contact you first [7:24pm] _tmatsuo: Looking through App Engine Product Roadmap, there is 'mapping operations across datasets' is on Deck. What doesit exactly mean? [7:24pm] ikai_google: Wooble: Now, if it's really bad stuff, we will shut you down first and ask questions later. [7:24pm] ikai_google: _tmatsuo: Map/Reduce [7:25pm] lambo4jos: any info on the # Datastore dump and restore facility that is listed on the roadmap? [7:25pm] jason_google: Wooble: We'll generally always contact you first unless it's clear that your violation is malicious (e.g. you're phishing) or your app is seriously impairing our back-end. [7:25pm] _tmatsuo: ikai: cool. with task queue like mechanism? [7:25pm] ikai_google: lambo4jos: Nothing for you yet [7:25pm] skot: Has there been any talk of increasing the urlfetch size? I have need to upload 5+ Mb items. [7:25pm] lambo4jos: [7:26pm] jason_google: lambo4jos: Have you seen http://code.google.com/appengine/docs/python/tools/uploadingdata.html? [7:26pm] Wooble: well, I'm more concerned about users of an app that allows user-contributed content being abusive then me doing evil stuff. I know I can trust myself [7:26pm] ikai_google: _tmatsuo: I don't remember. I saw an early demo using that type of interface (HTTP action), but it was just a proof of concept [7:26pm] jason_google: skot: Can you just split this request into smaller requests? [7:26pm] ikai_google: _tmatsuo: My expectation is "yes" since we've kind of been following that pattern [7:26pm] skot: Not on uploads, I can do range requests on downloads. [7:26pm] _tmatsuo: ikai: thx [7:27pm] lambo4jos: jason_google: yeah, i have been working with app engine for a while, but have never attended this chat [7:27pm] ikai_google: Wooble: Yeah, that's tough. We won't police your content, but if it's reported we may take action. [7:27pm] jason_google: By "take action", we'll probably report it to you first though. [7:27pm] skot: jason_google: I'm passing images through, and they would be relatively large [7:27pm] ikai_google: Wooble: Wish we had a better solution for you. I've seen solutions like: require approval, mechanical turk, etc [7:27pm] lambo4jos: the articles such as the one you have posted are very useful.. great documentation by you guys [7:28pm] jason_google: lambo4jos: That page has some basic information on how to do a dump and restore. [7:28pm] _tmatsuo: I've reported an issue about InboundMailMessage. We have difficulties on decoding message body because of this issue. Could you please take a look and notify this the team? http://code.google.com/p/googleappengine/issues/detail?id=2326 [7:29pm] jason_google: skot: What's more likely than increasing the 1 MB limit is allowing you to pass a blob key, which is similar to what we're doing for some image service functions. But I'm not sure if this is planned at the moment. It's certainly a good request. [7:29pm] Wooble: Flickr's solution seems to be require approval and then ignore everything after approval, which is great if you own the hardware and can ignore your own TOS [7:29pm] ikai_google: _tmatsuo: I'll take a look at it. [7:30pm] lambo4jos: i actuall attended to get some clarifications on transactions [7:30pm] lambo4jos: i am under the impression that transactions on a single entity or single entity group happen sequentially, and not concurrently. [7:30pm] lambo4jos: is my thinking correct? [7:30pm] moraes: Wooble, just add a little flag for others report. no worries. [7:30pm] moraes: [7:31pm] jason_google: lambo4jos: Transactions that result in a write do occur sequentially, yes. [7:31pm] _tmatsuo: ikai: thx! [7:31pm] jason_google: lambo4jos: Two updates to the same entity/ entity group cannot occur in parallel. Which is one reason we encourage you to keep your entity groups as small as possible. [7:31pm] skot: jason_google: that is good for collection of the data into appengine, but if you have to use a public service that doesn't allow "chunked" uploads you can never push it on to that service (like flickr, or picasa-web) [7:32pm] skot: jason_google: does that make more sense? [7:32pm] jason_google: skot: Yes, it makes sense. Have you filed a feature request? Like I said, the blob key implementation is more likely, given the direction the team took with the image service functions, but it's worth filing. [7:33pm] lambo4jos: jason_google: thanks for the clarification. i had a tough time understanding how to model my data, but just realized thats how transactions work [7:33pm] skot: jason_google: no, I haven't filed a request; I will. [7:33pm] lambo4jos: in regards to a transaction failure, or any datastore failure, does a failure consume datastore quota? [7:34pm] jason_google: lambo4jos: You're probably charged with the datastore CPU time it took to make the initial calls, yes. But not with the storage unless the write actually succeeded. [7:35pm] moraes: did you guys ordered an iPad already? [7:35pm] • moraes runs [7:35pm] jason_google: moreas: Still trying to convince the wife. [7:35pm] bthomson: timeouts at least don't cost any api_cpu quota anymore [7:35pm] enigmus: Alright, burning question: issue 901 and 2481? To use an analogy, returning wrong results for a database is like faulty gas pedal on a Toyota: you would expect a recall and a shutdown of the production facility until the problem is resolved. 901 is 1 year old. What's going on? [7:35pm] AreEmmKay: is there a fix yet for the "doing anything in the SDK console breaks Django 1.1" issue? [7:35pm] lambo4jos: how about if the datastore succeeds but returns 'None'. does that consume datastore api call quota? [7:36pm] skot: jason_google: looks like issue 1365 covers this need for larger urlfetch sizes (both directions) Do you want me to create another issue? [7:36pm] moraes: lambo4jos, sure. [7:36pm] moraes: api call was spent after all. [7:37pm] moraes: enigmus, are those issues still valid? i had similar ones, but it's been quite a while... [7:38pm] ikai_google: enigmus: I need to double check, but the issue is that indexes are incorrectly created [7:38pm] jason_google: enigmus: I need to look at 901 a bit more. Regarding 2481, I've been meaning to update that stream since I know a lot of people are still seeing it. We're taking it extremely seriously, but it's taken awhile to both find the core issue, find it, and correct the data in the datastore. I've been told that it should be relatively soon, "weeks" but not "months". I realize that isn't very satisfactory, but we are working on it. [7:38pm] ikai_google: enigmus: So what ends up happening is that for small datasets, a single put one by one will fix it [7:38pm] lambo4jos: from the docs: http://code.google.com/appengine/docs/quotas.html under datastore it says "The total number of times the app retrieved, created, updated or deleted an entity, or performed a query in the datastore." [7:38pm] lambo4jos: if a db.get returns none, it didn't retrieve anything, but moraes, you are saying it consumes quota? [7:38pm] lambo4jos: but i guess it is a query? [7:39pm] moraes: lambo4jos, yes, i guess so. it used a rpc call. doesn't make sense? [7:39pm] AreEmmKay: Random thought-- URLFetch should be more like cron, task queue, and even blobstore-- you request a file and provide a callback URL, Google fetches the file and posts it (or a proxy object, like BlobInfo) to the URL. [7:39pm] ikai_google: ikai_google: But we've got two other issues: making it so our mass index update works so we can build large indexes without issues, and fixing retroactive datasets. This is in addition to finding the problem [7:39pm] jason_google: lambo4jos: The query still occurs, even if doesn't return any entities, right? [7:39pm] ikai_google: oops responded to myself [7:39pm] jason_google: Ha ha [7:39pm] moraes: moraes: haha [7:39pm] moraes: oops [7:40pm] lambo4jos: it should not consume 'Data Received from API' though if it is None? or am I incorrect? [7:40pm] ikai_google: enigmus: We've found the problem and are fixing it, but the fix isn't rolled out yet [7:40pm] jason_google: lambo4jos: I believe that's true, yes. [7:40pm] _tmatsuo: lol [7:40pm] ikai_google: lambo4jos: It still takes data to return a null value [7:40pm] lambo4jos: jason_google: yeah it is a query. i was hoping it wasn't. [7:41pm] ikai_google: lambo4jos: Well, a query has to happen for us to find out nothing is there [7:41pm] skot: AreEmmKay: sure, but some of us need synchronise access, without a callback. I am just proxing some data from one service to the client (in a secure fashion) without the need to store it. [7:41pm] jason_google: lambo4jos: As Ikai notes, maybe you're charged but I would think it would be negligible. Much smaller than returning actual entity results with StringProperties, TextProperties, etc. [7:41pm] Wooble: I'm guessing the overhead for serializing "None" and sending it back is fairly small [7:41pm] lambo4jos: ikai_google: ok. got it. [7:41pm] jason_google: Wooble: Me too. [7:42pm] _tmatsuo: This question might be too detailed but, I've glanced through an implementation of google.appengine.tools.bulkloader.IncrementId method. I feel like in most cases, this implementation is sufficient for preventing conflicts of autogenerated IDs, but not perfect. Is there any plan for improving this implementation? [7:42pm] moraes: can we use same protocol buffer library used internally? [7:42pm] AreEmmKay: skot: OK, then my idea supplements rather than replaces URLFetch. Call it FetchLater [7:42pm] moraes: ^ random question, i'm thinking on doing something, could research a bit rather than ask. [7:42pm] jason_google: AreEmmKay: Python has asynchronous URL Fetch and Java is getting it soon. Not quite what you have in mind but it's better than synchronous requests, especially if your handlers have a lot of logic or other API calls. [7:42pm] skot: _tmatsuo: I would tend to agree. I had to write my own. [7:43pm] ikai_google: moraes: Yeah, you can take a look at any of our stuff that is exposed and use it. The only thing is that it is subject to change. There was a framework - I think it was a blog framework - that did this, and it broke when we did an SDK update [7:43pm] skot: AreEmmKay: As jason_google said, it is now in the java sdk for 1.3.1. [7:44pm] jason_google: _tmatsuo: I wish Ryan was here. I'm not completely sure about the implementation, but I would expect it to be pretty hardened against producing duplicate IDs given that that would result in data loss/corruption. [7:44pm] enigmus: What are the details behind is the User API? Is it cookie based? And if so, how can it possibly be safe from various types of XSS? (like B.com using a <script src="A.com/auth/rpc/call"> [7:45pm] moraes: auth has to be cookie based [7:45pm] ikai_google: enigmus: Making it safe from XSS is your responsibility [7:45pm] ikai_google: enigmus: We protect the login page [7:46pm] jason_google: enigmus: I believe it is cookie-based, yes. The cookies are for the particular appspot.com domain (or Google Apps domain) that you're on, which is why you have to sign in to all App Engine apps individually. [7:46pm] ikai_google: enigmus: But after that, on form submissions and such [7:46pm] ikai_google: enigmus: It's up to you to place CSRF tokens, etc [7:46pm] Wooble: it would be kind of nice if I could sign out of an app engine app without losing my gmail session, since the login has to be done separately. [7:46pm] _tmatsuo: jason: afaic, our data will be safe, the datastore API raise an error when newly generated ID is already in use. [7:47pm] jason_google: Wooble: As a regular Gmail and App Engine app user, I agree. [7:47pm] enigmus: ikai_google: makes sense. I'm not sure the doc is clear enough on that, however. Maybe I missed it. [7:47pm] moraes: the protocol buffer implementation in python has decent performance? or the one used internally is not public? [7:48pm] ikai_google: enigmus: I think we may need to write a security article in general, but it would apply to all websites and not just App Engine. You have the same problems if you are using Facebook Connect, Twitter Auth, etc [7:48pm] jason_google: moreas: I believe we use the same implementation that's open source -- same optimizations and so forth. [7:48pm] jason_google: moreas: Or, at least, I don't know otherwise. [7:49pm] lambo4jos: for 1.3.1 sdk, can someone please share what transactional tasks are? [7:51pm] manster: hey whats the difference between this grp and the other one [7:51pm] manster: appengine [7:51pm] moraes: also, why nexus got multi-touch? everybody is wondering about the apple patent. [7:51pm] Wooble: manster: this one works at the moment, and that one was borked. [7:51pm] • moraes only asks silly questions [7:52pm] manster: i seee [7:52pm] ikai_google: lambo4jos: There's a lot of different things happening in transactional tasks, but it was a feature we created to deal with a lot of errors where a task would blow up mid-execution. I'd wait for the final documentation to see everything it does, but a big part of it is just making task queues more reliable in general [7:52pm] manster: so any ideas [7:52pm] manster: http://pastie.org/808800 [7:52pm] Wooble: lambo4jos: from a post to the java group last week, I *think* it means you can enqueue a task inside a transaction and it will take place within that transaction, but then again I think the java API uses Transaction in some confusing ways. [7:52pm] ikai_google: manster: We have a temporary issue with the other group [7:53pm] jason_google: lambo4jos: I found a reference in a recent post from Max Ross: [7:53pm] skot: For the new urlfetch async in java, is there a limit to the size of the class (for serialization) that implements Future? [7:53pm] jason_google: lambo4jos: Once the feature is enabled, tasks that are added to queues when there is an active datastore transaction will be automatically enlisted in the datastore transaction so most of the time you won't actually need to get ahold of the active com.google.appengine.api.datastore.Transaction. [7:53pm] moraes: manster: the other si the official one. however because of spam it is set to registered only and people coming to the chat didn't had account so we created this one. [7:53pm] ikai_google: manster: This is a GWT question? you may want to ask in the GWT forums [7:53pm] moraes: it is not like app engine version 2 or something. [7:53pm] moraes: [7:54pm] _tmatsuo: A prerelease process is very nice, it helps me a lot for developping my own framework, but currently its restricted in local dev server. When will it be applied to the real server environment? [7:54pm] lambo4jos: jason_google, Wooble, ikai_google: nice, i am looking forward to reading the documentation on it [7:54pm] ikai_google: _tmatsuo: Soon [7:54pm] moraes: "soon" [7:54pm] _tmatsuo: "soon" [7:54pm] ikai_google: _tmatsuo: Sorry, we'll let you know ASAP [7:54pm] moraes: couple of weeks you can bet. [7:54pm] jason_google: skot: I'm not exactly sure, but I would think that it should work sufficiently for most classes. [7:55pm] jason_google: Yes, moraes has the right idea. [7:55pm] Wooble: it's more fun to RTFS and figure out what it does, but I haven't downloaded the pre-release yet. [7:55pm] _tmatsuo: ikai: thx! dont get it wrong. [7:55pm] moraes: guys, any new exciting app engine project you saw recently? [7:55pm] jason_google: But, in the meantime, if you find any bugs in the SDK, let us know about them now so we can fix it before 1.3.1 lands for real. [7:55pm] ikai_google: Is it a couple of weeks? Thought it would be sooner. This is maybe the 2nd time we are trying prereleases [7:56pm] jason_google: ikai_google: Within a couple of weeks, assuming everything goes well with the pre-release. [7:56pm] lambo4jos: i was watching the video from google i/o by Max Ross, Softer side of schemas, and he mentions a safe write throughput for a single entity group is about 1 to 10 per second. [7:56pm] skot: ikai_google: I like the pre-releases, but I like them even better when they work in dev and prod. [7:56pm] lambo4jos: any idea what the size of such an entity group would be that could get this kind of write throuhgput? [7:57pm] ikai_google: skot: We can't put them into prod until we have some level of confidence. Maybe the long long term solution is to have a Beta prod server with low quotas [7:57pm] skot: ikai_google: sure, let us choose our level of danger. [7:58pm] ikai_google: lambdo4jos: A lot of these numbers are very soft. It's not just hte size of the group, it's also the size of the index update [7:58pm] enigmus: Any comments on: http://gaejava.appspot.com/? JDO looks a lot smaller than the low-level Java API [7:58pm] Wesley_Google: download the prerelease of SDK 1.3.1 at http://bit.ly/cmqXGT [7:58pm] Wesley_Google: or at least, *read* about it b4 u download it [7:59pm] ikai_google: lambdo4jos: So it's really up to you to benchmark. [7:59pm] jason_google: enigmus: Interesting app, I hadn't seen it before. Technically, JDO and the low-level API are using the same implementation. JDO is just a wrapper. [8:00pm] jason_google: enigmus: I'm seeing the low-level API outperform JDO actually, which makes sense. [8:00pm] jason_google: Due to all the DataNucleus overhead [8:00pm] takeru: Can I know api cost for each call? 1put=48api_cpu_ms, 1index=16api_cpu_ms, etc.... [8:00pm] enigmus: jason_google: sorry, I meant "JDO looks a lot slower than..." [8:00pm] lambo4jos: ikai_google: got it. [8:01pm] enigmus: jason_google: yeah, that's my question. Is the JPA overhead lower? [8:01pm] manster: how can you use appengine and not know gwt? i dont understand [8:01pm] jason_google: enigmus: Right. Technically, the actual low- level calls are the same, but I'm guessing the ORM layer adds some overhead. JPA would likely be similar. [8:01pm] skot: enigmus: where is the source for that app? I'd love to provide another framework for comparison (another wrapper on the datastore api). [8:01pm] enigmus: jason_google: A factor of 7x between JDO/low-level is a bit scarry. [8:01pm] skot: manster: LOL [8:01pm] enigmus: skot: it was posted on the mailing list at some point I believe [8:02pm] skot: enigmus: cool, I'll search. [8:02pm] jason_google: enigmus: I'd have to know how it's implemented, e.g. if the low-level is using batch puts. It's possible to do batching with JDO but it's not automatic. [8:02pm] moraes: manster, you know pyjamas? [8:02pm] manster: what other kind of app would you be making? [8:03pm] moraes: manster, there're lots of ways to make web apps besides gwt. [8:03pm] skot: manster: web service with no UI [8:03pm] moraes: not all apps have user interface. [8:03pm] manster: oh snap [8:03pm] enigmus: jason_google: I believe the author is doing batches, at least he claimed so, if I recall. [8:03pm] manster: almost forgot. and thats no fun [8:03pm] lambo4jos: moraes: have you used pyjamas? if so, what are your thoughts? [8:03pm] jason_google: enigmus: I'll look into it a bit more. Thanks for sharing it. [8:03pm] Wesley_Google: does anyone have any Python-specific questions (App Engine or otherwise)? [8:04pm] enigmus: jason_google: but even for the a single put, there is still a factor of 7x. [8:04pm] moraes: lambo4jos, i didn't! i want to play with gwt actually. maybe after my android adventure. [8:04pm] manster: if you dont build an app with gwt i did not think you could deplow to the appengine [8:04pm] _tmatsuo: Currently, taskqueue is in the lab, when will it graduate, and how? [8:04pm] manster: deploy* [8:04pm] ikai_google: manster: Nope, standard JSP will work [8:04pm] moraes: Wesley_Google, i do. [8:04pm] lambo4jos: moraes: looks pretty cool [8:05pm] Wooble: manster: you can actually have plain old python CGI applications. basically anything that responds to HTTP requests will work fine. [8:05pm] jason_google: We've reached the end of the chat! Sorry for starting late -- we'll work on getting the issue with the other channel sorted out. I'll be in the channel for the next few minutes, and I'm sure Wes will be also, in an unofficial capacity. The next formal Chat Time is in two weeks, Wednesday, February 17th from 9:00-10:00 a.m. PST. [8:05pm] ikai_google: Hey, informal poll here: do you guys like using groups for questions? Or does something like StackOverflow work better for everone? [8:05pm] manster: well thats hella good to know [8:06pm] enigmus: ikai_google: group's good. [8:06pm] moraes: i have 150 points in stack overflow. [8:06pm] _tmatsuo: ikai: group+ [8:06pm] jason_google: enigmus: Do you use all 3 groups or just 1 in particular. [8:06pm] jason_google: Would you guys use Stack Overflow more if we were more active in answering questions there? [8:06pm] bthomson: group > stackoverflow [8:06pm] Wooble: ikai_google: I like both; stackoverflow works great for simpler questions, but for involved discussions the group works better. [8:07pm] lambo4jos: i agree with Wooble: groups == discussions, stackoverflow == simple_solution [8:07pm] Wooble: I can beat nickjohnson and alex martelli to an answer like once out of every 10 questions. that's probably active enough [8:08pm] ikai_google: Well, I ask because there are a lot of questions in the groups [8:08pm] ikai_google: where stackoverflow would be a better place to answer [8:08pm] moraes: i hate that when i google something i find those osdir.com before google groups. i downvote them, always [8:08pm] enigmus: jason_google: the java one and the main one. It can be a problem as most technically involved discussion concern both Java and Python, reallu. [8:08pm] ikai_google: now, discussion type things [8:08pm] ikai_google: should belong in the groups [8:08pm] _tmatsuo: Wooble: makes sence [8:08pm] enigmus: ikai_google: Yeah, it's true. A kind of "dynamic" FAQ, like stack overflow provides, would make sense from that point of view. [8:08pm] skot: ikai_google: is there a plan to take some of the group discussions and make them into FAQs or articles? [8:08pm] ikai_google: anyway, we're thinking about it since the Android guys are toying with StackOverflow [8:08pm] jason_google: Ikai's right. I'd say that the majority of new topics are questions, actually. If we ever moved to Stack Overflow, we'd keep at least one group open for discussions on data modeling, etc. Do you think that breakdown would work? [8:09pm] Wesley_Google: the interesting thing is that SO is crowded by daily app engine developers while the groups are monitored by us, who aren't necessarily app engine developers as a profession... [8:09pm] moraes: ikai_google, are you thinking to do with SO the same that you've done with android? [8:09pm] Wooble: moraes: I agree, but of course if you have google searches favoring google groups, people would start to scream about bias. uh, even though that's where the original posting was [8:09pm] ikai_google: Maybe, and maybe all Google Developer Programs in general [8:09pm] ikai_google: I know Google Wave uses Waves for stuff [8:10pm] moraes: So is a great source anyway [8:10pm] moraes: i frequesntly search using site:stackoverflow.com [8:10pm] ikai_google: I mean, the best, most ideal solution is this: you have a problem, you connect your brain to the hive mind, and we all solve it together [8:10pm] enigmus: jason_google: The source code for gaejava.appspot.com was posted on http://groups.google.com/group/google-appengine/browse_thread/thread/7930b99e57cc59d9/bce350a287713ed7 (at least an early version of it) [8:10pm] jason_google: We're just brainstorming at this point. I like the idea of Stack Overflow more than groups personally. It's a lot better for searching for old questions and determining when a question has been answered or is still waiting on an answer. [8:10pm] Wooble: I got sort of disillusioned with wave's performance early on, but I think when it's working well it would be great for this sort of thing. [8:10pm] ikai_google: but in the absence of that technology, what's better for that? Groups, in a serial post format? Or stackoverflow with the question, comment, comment, dedup model? [8:10pm] jason_google: Thanks enigmus. [8:11pm] enigmus: ikai_google: stack overflow kind-of-thing, I would say. [8:11pm] ikai_google: anywaym thanks for the feedback guys [8:11pm] lambo4jos: i have found many answers to programming errors on stack overflow. google groups have been more theoretical solutions and suggestions for approaches [8:11pm] ikai_google: I'm popping out of here. See you guys in the groups/next time [8:11pm] moraes: both. why groups need to not exist. SO is more a big, useful wiki. [8:11pm] moraes: thansk for coming, guys [8:11pm] enigmus: jason_google: looks like it's not the version running right now, though. Maybe the author can be contacted by email. [8:11pm] ikai_google: moraes: understood. I actually think what the Android folks do is point more specific code questions to SO [8:12pm] ikai_google: and design questions to groups [8:12pm] jason_google: Thanks Everyone. I'm ducking out too. Sorry again for all the trouble earlier. Have a good evening/morning/ afternoon, depending. [8:12pm] lambo4jos: thanks for you help everyone. keep up the good work [8:12pm] _tmatsuo: thanks guys! -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
