hi andy openid - I really wish Google would just build support for FriendConnect directly into GAE. I don't have a good answer for you right now, maybe someone else has done this already. that being said, Nick built the very useful AEoid plugin: http://bit.ly/75CEy5
remote disable - there's actually two kill switches in our app but there are probably others you could use. I'm leaning towards 1 now, its more flexible 1) a cron job contacts our controlling GAE app, it can tell the app to shutdown. this controlling app has a simple web UI where we store client information (for instance, our 3rd party purchasing service Avangate contacts this server with any online purchases for all relevant accounts). Out clients cannot disable cron jobs and they cannot see the urlfetch requests to the controlling app (although I suppose Google could update the UI for this at some point) 2) we will be automating deployment using a native app on EC2. It powers appcfg.py using additional metadata for each known instance. Since this is automated, an extra site_config.txt file is (re)written for each deployment. This file contains license info and a validity date so the killswitch is hard-coded (note - the only way to update this file is via appcfg, so if you need more flexibility, the cron request route may be easier) and finally, I forgot to mention another pro/con of this setup. 1) since all of our clients have their own GAE app, they also have access to their own GAE free daily usage limits. Running this as a service would have eaten these limits up very quickly (we are dealing with a lot of data) but now they are spread evenly over each client. over the course of a year, this is significant (although I'll have better metrics as this year progresses) 2) conversely, each client then has to deal with the dreaded "cold start" issue. The significance of this widely depends on how their data is being accesses but I still think it's the biggest issue with GAE right now (Nick - did I read correctly on the GAE-Java forum that their instance should be keep alive for an *hour*?) cheers brian On Jan 19, 1:56 am, Andrew Chilton <[email protected]> wrote: > Hi bFlood, > > 2010/1/19 bFlood <[email protected]>: > > > that is how we will be deploying our app. Users add a specific email > > address as a developer and then we load/maintain the source code > > remotely. A simple cron request makes a call back to our controlling > > app (on GAE) so we can change limits, upgrade features or turn off the > > remote app (in the event they subsequently remove the developer email > > account and stop paying). There are probably many other ways to combat > > this issue > > Wow, cool. I've been thinking of setting up one app for a while and > letting other Google Apps just add it via their accounts. Separating > data for each mapped domain seems to be easy enough, but letting lots > of people from different Google Apps Domains log in seems to be the > hardest thing to do (so your suggestion above seems to get around > this, thanks). > > For more information about my login issues/problems, > see:http://groups.google.com/group/google-appengine/browse_thread/thread/... > > Further to this, I tried OpenID and the federated login, but it seems > the IDP stuff (or whatever it is extra in the federated login > (discovery?)) isn't liked by the Python OpenID library (yet?). It > makes me sad this is so hard to set up. It seems the Google Labs > ShortLinks service somehow works exactly how I would like mine to but > I'm yet to find an answer as to how they did it. If anyone knows, I'd > be very grateful :) > > > this setup works well in practice. The user pays Google directly for > > usage and then licenses the software from us. It turned out to be a > > lot easier then running it as a service (single GAE app) and having to > > be the middle-man between the user and Google. Trying to estimate how > > they would be billed per month was difficult and seemed like a > > duplication of the existing infrastructure. Also, a flat fee might > > have been more profitable (or not) but IMO does not play to one of > > GAE's biggest strengths, true utility billing. > > Maybe this is the way forward for me. I guess there is also some way > to remotely disable the app (e.g. when their license is up) since > otherwise the user could just disable your access to the AppEngine > control panel. I guess your application has something like this in it? > Of course, this solution doesn't scale for hundreds or even thousands > of users so I'm kinda hesitant to do it. I'd love if you could > reassure me it can be done. :) > > Cheers, > Andy > > -- > contact: Andrew Chilton > website:http://www.chilts.org/
-- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
