fireeagle integration

Brady, think more creatively. The only feature that needs the constant polling is the "Near Me" feature. Even if this is a heavily-used, gotta-have-it feature (is it?), you could still pull the current location upon status change rqst/place checkin rqst. This would meet the needs of most folks commenting here and get you to market in a day or two. Then, once you solve the scale issue, roll out the new solution.
It's a couple of calls and a preference item for "use FE's location when changing status". Easy-Peasy... ( Delete or Edit)

@jeppedy Exactly what I was going to suggest, for starters if you showed where fireeagle thought i was at the check in page that would be a huge value add. and that should be pretty trivial. ( Delete or Edit)

How is Pownce doing it then? ( Delete or Edit)

As I understand it, the reason Pownce has no difficulty integrating with FireEagle despite their size is because it only ever needs to know where you are when you post something. So a user action prompts the pull from FE; this is more scalable because it does not have to be happening all the time, only once in a while when you post something.

This is equivalent, in terms of practicality, to the suggestion that BrightKite should prompt the you, when checking in, to just pull from FE (also like @FE mentioned earlier).
I think this is very sensible and, from the sounds of it, feasible.

Some people might want BK to check you in automatically whenever your FE is updated (from Plazes or any other service that pushes your location to FE). This is nice because it means you will only need to check in with one service and all your FE-capable services (e.g BK, Plazes or Pownce) will be updated instantly and automatically.
This is very difficult; because it demands that BK constantly lookup the location of all of its users through FE to make sure they haven't gone from their last check in point.

I think, until FE itself supports pushing relevant data to BK (i.e when a BK user's FE location is updated, FE should let BK know to pull the new geodata), the @FE user-prompted pull is a clever and effective compromise. ( Delete or Edit)

Request for Brightkite developers - please consider other options for your international users as well.

For example, sending @FE via text or mobile email might seem like a good answer for your US users. But living in Asia, neither of those really works on a long term basis.

I understand that it's difficult for you to poll FE and am willing to put up with the hassle of having to update BK separately to pick up FE data. But please give us an option via the mobile site as well! ( Delete or Edit)

Thanks for the update Lesley. Looking forward to the announcement! ( Delete or Edit)

polling is stupid by default, and I mean *too stupid to do it* -- wasting resource for almost nothing. ( Delete or Edit)

This does not address the issue of 2 way integration with Fire Eagle. Given that FE now has a XMPP PubSub endpoint, one would think you have the ability to have an implementation that does not rely on polling.

http://tech.groups.yahoo.com/group/fi... ( Delete or Edit)

I see that Jauder has mentioned the new XMPP platform here just now, but I've also started a new thread about that here - http://getsatisfaction.com/brightkite... ( Delete or Edit)