[09:06] <scudder_google> Hey everyone, we're ready to start another hour long chat session. [09:08] <scudder_google> We have some Googlers here, myself, jason_google, jcgregorio_google, dan_google, nickjohnson, and some others may jump on a bit later [09:09] <Wooble> ok, I knew this channel was dead when these chats weren't going on... [09:09] <scudder_google> ribrdb is here from Googler too :) [09:10] <dan_google> Anyone want to plug their App Engine site? [09:10] <dan_google> And by plug I mean promote. :) [09:10] <knoonan> Hi guys, apart from housekeeping on the datastore, do you anticipate that remote_api will be used to enable desktop applications which use BigTable as a datastore? [09:11] <dan_google> knoonan: That's a fine idea, I don't see why not. [09:12] <HighBit> hey guys. just saw jcg mention the chat on twitter. so what's new w/ app engine? :) [09:12] <bFlood> @dan_google - but they would need your admin logon for remote_api right? [09:12] <scudder_google> knoonan and bFlood: actually I don't think admin login is required [09:12] <dan_google> bFlood: Yeah, to use remote_api directly you would. Or another admin account. [09:13] <dan_google> bFlood: You can always set up the remote_api handler to not have admin protection. Not sure if that's a good idea. [09:13] <dan_google> In general, it's probably better to build just the web service end points the desktop application needs. [09:13] <Wooble> maybe hack the handler to do its own authentication? [09:14] <Wooble> whether that's significantly better than using a RESTful interface I have no idea... [09:15] <bFlood> Wooble - yea, I kinda came to the same conclusion. just use a RESTful endpoint instead, easier to work with [09:15] <bFlood> but at first I thought remote_api would be great for desktop to connect in [09:16] <Wooble> well, it would allow you more flexibility in what your desktop app would be able to do without deploying a new version of the server side app, definitely. [09:16] <scudder_google> knoonan and bFlood: I was wrong :) the remote API handler checks for an admin even if login:admin is not specified in app.yaml [09:16] <dan_google> bFlood: If your end points would essentially expose the same functionality, I don't see a problem. But for most apps I can imagine, you'd want custom partitioning of the datastore on a per-user basis, enforced by the endpoints and some auth. [09:17] <dan_google> But Google Accounts might be sufficient auth. [09:17] <dan_google> (I retract my statement about admin-less remote_api as well, then. :) ) [09:18] <bFlood> dan_google - google accounts auth seemed to work best for our scenario [09:18] <bFlood> maybe offtopic but do the callbacks for the future async urlfetch/datastore run on independent threads? [09:19] <dan_google> I'm not aware of any plans to do async urlfetch/ datastore. Where is that from? [09:19] <bFlood> pubsubhub codebase [09:20] <bFlood> this forum post has more info: http://tinyurl.com/d3uton [09:21] <HighBit> I noticed jaiku uses jabber (via gtalk) -- I haven't looked at the code, has anyone looked at that? [09:21] <HighBit> I'm curious how they integrated jabber with app engine [09:21] <dan_google> My understanding is that pubsubhub is using all public features, and I'm not aware of any async urlfetch/datastore. Can you point to a spot in there that looks like it's doing async? [09:21] <bFlood> async_apiproxy.py [09:23] <bFlood> it does seem to work for urlfetch (see the MegaFetcher example from the post above) and it also seems to work for datastore [09:23] <scudder_google> HighBit: We are planning to make an XMPP API available publicly at some point in the next several months [09:23] <scudder_google> HighBit: as noted on our roadmap [09:23] <HighBit> ah. [09:24] <bFlood> but I cant tell if the callbacks are run on real background threads (or just the datastore fetch) [09:25] <scudder_google> HighBit: I'm not sure about Jaiku's implementation though, but you can check out the source code http://code.google.com/p/jaikuengine [09:26] <dan_google> bFlood: I'll have to look into it and get back to you. [09:26] <knoonan> I'll plug a friend's app: "LongURLPlease" by Darragh Curran. For all of those "tiny URLs" we encounter--it automatically expands them so you know where a click will take you... [09:26] <HighBit> scudder_google: yea, I wanted to, haven't gotten aronud to looking at their code yet. I think it's pretty nifty that it was open sourced though. [09:27] <HighBit> I hope they have at least some testing in there; I want to see some app engine tests in action [09:27] <bFlood> dan_google - ok, thanks. it would be a nice addition. I would be using the same CPU per request, just in parallel instead of serially (I guess you could argue either way as to which is better for GAE's scalability) [09:28] <MBoffin> knoonan, I turn on TinyURL's preview feature. That way TinyURL won't auto-redirect me. First it shows me where it will take me. But LongURLPlease sounds cool because not all of those URL services give you a preview mode. [09:28] <knoonan> It's available as a Firefox plugin. Over 4,000 users already & ten external applications using LongURLPlease as a service, thro' its RESTful interface. [09:29] <ribrdb> bFlood: If you look at async_apiproxy you can see that the callbacks get run when you call wait. There's no threads involved. [09:30] <jcgregorio_googl> knoonan: nice! particularly handy for twitter [09:31] <bFlood> ribrdb - cool, thats why I was asking :) I was getting different hashes for the threading.local() in the callbacks so I didnt know [09:31] <HighBit> are there any articles (planned) for GAE testing? [09:32] <dan_google> HighBit: We definitely want some. If you'd like to write one, we'd publish it in the docs. =) [09:33] <HighBit> cool. I'm new to python (big perl guy) so learning python and explroing GAE is a side project. I would certainly like to write something tho, I'll let you know if I actually do! [09:35] <HighBit> I know brad f. had a perl app engine side project that sort of withered. seems like Perl 5 isn't the best fit for something like GAE where the env. has to be so controlled [09:35] <dan_google> HighBit: The loading of the service stubs for the purposes of unit tests is underdocumented, it's been on my to-do list for a while. It's definitely possible, and something we'd like to promote more. [09:35] <HighBit> the Perl source itself is fairly.. messy.. and there are many ways to do things :) [09:35] <HighBit> *nod* [09:37] <Wooble> HighBit: I maintain my faith that Brad just ditched the community aspect and finished that project himself secretly, and Perl support will be announced Real Soon :) [09:37] <HighBit> *grin* [09:42] <MBoffin> I'm just getting back into GAE, so I may have missed a blog post or two about the subject, but is there any expressed timeline yet for supporting other languages? [09:42] <HighBit> MBoffin: the road map at http://code.google.com/appengine/docs/roadmap.html mentions soon [09:42] <HighBit> hopefully by june [09:42] <MBoffin> Great, thanks. [09:42] <HighBit> my totally speculative guess is that it'll be Java [09:43] <nickjohnson> Is anyone running a pool? [09:43] <Wooble> I'm betting on SmallTalk. [09:44] <dankles> maybe it will be ANY x86 compiled code you want! Google already figured out how: http://nativeclient.googlecode.com/svn/trunk/nacl/googleclient/native_client/documentation/nacl_paper.pdf [09:45] <HighBit> dankles: interesting! I didn't think of putting those together [09:45] <Wooble> considering they won't allow compiled python modules, that seems unlikely.... [09:46] <bFlood> my guess is java [09:46] <dankles> yeah, probably not, but it would be amazing if they pulled it off [09:46] <dankles> anyway i'll stick with python :) [09:47] <flpatriot> so, how is background processing going to work? [09:48] <brett-appengine> hey sorry i'm late [09:49] <bFlood> plug - here's a sample Flex based viewer running spatial-like queries in GAE. http://tinyurl.com/anpq5p [09:49] <scudder_google> flpatriot: there are a couple of things we're planning to release for background processing [09:49] <nickjohnson> How are you indexing the data? [09:49] <scudder_google> flpatriot: scheduled tasks, and task queue [09:51] <flpatriot> scudder_google: where are tasks scheduled - app dashboard, code, config.yaml, or something else? [09:51] <scudder_google> flpatriot: scheduled tasks is similar to cron, if you are familiar with that. Is that the kind of info you are looking for? [09:52] <bFlood> nickjohnson - grids of geometry, rtree-like indexes in the grids. good for small bbox based queries but its no RDBMS for heavy lifting. more here: http://tinyurl.com/c6ps3g [09:52] <flpatriot> scudder_google: a slightly more specific timeline than "sometime before june" would be nice ;) [09:53] <dan_google> flpatriot: Sometime before June 30th. ;) [09:53] <dankles> lol [09:53] <Wooble> see, that's even worse. more like "before July" [09:53] <dankles> keep asking & it might end up in 2010... [09:54] <pr3d4t0r> Hrm... [09:54] <pr3d4t0r> dan_google: Hej. [09:54] <nickjohnson> bFlood: Have you seen the various space-filling indexing solutions? [09:55] <nickjohnson> I have a rather primitive implementation here: http://gist.github.com/40102 [09:55] <bFlood> nickjohnson - like which ones? [09:55] <pr3d4t0r> Q. Is there an announcement yet about the additional programming language supported for App Engine? I'm speaking about hybrid cloud/enterprise systems in a few hours at TheServerSide Java Symposium and I'd like to include this if it's known. Thanks in advance. [09:55] <nickjohnson> Others are also working on similar [09:55] <nickjohnson> pr3d4t0r: There's no official announcement of which language it is, if that's what you're asking [09:55] <scudder_google> pr3d4t0r: no announcement yet [09:55] <scudder_google> :) [09:55] <pr3d4t0r> nickjohnson: Grrr.... [09:55] <pr3d4t0r> nickjohnson: OKi. [09:55] <pr3d4t0r> nickjohnson: Thanks :) [09:56] * pr3d4t0r sets the slide back to "Python only". [09:56] <brett-appengine> How about "Python + ?" [09:56] <brett-appengine> not the most useful but... [09:56] <brett-appengine> there will be other options [09:56] <Wooble> I bet the "new language" will be python 3, just to make people's heads explode. [09:57] <brett-appengine> haha [09:57] <gvanrossum> I think it's haskell [09:57] <pr3d4t0r> brett-appengine: That won't work. This is a gathering of senior enterprise guys, the kind who make decisions (engineering, architecture) and they want to know what's actually there, not what might be there :) [09:57] <pr3d4t0r> gvanrossum: w00t! [09:57] * cdent would love to see a haskell gae [09:57] <nickjohnson> I had my heart set on an esoteric language [09:58] <nickjohnson> At least they're easy to sandbox [09:58] * Wooble would love to see a fully functional FORTRAN runtime released on April 1st. [09:58] <dan_google> Wooble: You could probably implement Fortran in Python for this purpose. :) [09:59] <pr3d4t0r> gvanrossum: The presentation leans more heavily toward EC2/Nirvanix/Rackspace cloud instead of App Engine right now, mostly because of the tools and protocols supported. I'd love to have more infos here for that reason, to convince the philistines that App Engine is a viable option. [10:00] <dan_google> gotta go. see y'all [10:01] <cdent> pr3d4t0r: i don't know if it will work with the crowd you're talking to, but to me the app engine benefit is constraint: limited number of things to think about [10:02] <nickjohnson> There's also the relative maturity of the platforms to consider [10:02] <nickjohnson> EC2 has been around a long time, and has acquired a lot of features it didn't have at launch. :) [10:02] <pr3d4t0r> cdent: That translates into "non-mission critical stuff == good" :) [10:05] <bFlood> nickjohnson - cool stuff with geocell. the main problem I had was getting enough entities out of the datastore to test against the filter geom (point,line,poly). with grids I can work with a lot more data per request (without a huge amount of datstore hits) [10:09] <bFlood> hey jasonbirch - fancy seeing you here [10:09] <MatanCro> hey [10:10] <jasonbirch> hey bFlood ; shhh :) [10:10] <jasonbirch> I'm supposed to be working... [10:10] <bFlood> jasonbirch - mums the word [10:10] <scudder_google> We're just a bit over an hour now, so I'm going to call the "official" chat session closed. Some of us will hang around for a while longer. [10:11] <scudder_google> Thanks for all of the great questions and discussion! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
