I realize this is totally OT, but I thought folks might have fun discussing it, and I’m guessing you’ll have some great insights to share.
Basically, I have an idea for something that is a real-time notification system that takes advantage of geo-tagged messages that are intended for people “near-by”, meaning within a 10-mile radius or so. People will send out short geo-tagged messages using our mobile app, and if the app is running on your mobile device, then it will pick up the messages and determine whether to alert you or not based on your location and some other criteria. For something tangible, think of a system where a business would announce, say, free pizza at their Rural and University location for the next 20 minutes. (Again, over-simplified, but that’s the essence of the messaging, and how low-bandwidth it would be.) It NEEDS to be a dedicated app, not a plugin for something like FB or some other social media platform. How would you approach the messaging for this? Note that if the idea takes off, we’re talking about O(6) to O(8) numbers of apps running, anywhere in the world. One thing that comes to mind for me is to use Twitter as a transport mechanism and implement a simple messaging protocol on it that uses hashtags. It could be overkill, and possibly also not consistent with Twitter’s TOS. Just a thought. How else might you construct some way to broadcast short messages that are received by a large number of users in fairly short order? (ie., less than a minute). Also, as I mentioned, there is a “locality” effect that’s implicit in this application, as well as “timeliness”. So the further someone is from where a message originates, the less relevant it is. At some point, say, over 10 miles, they’re likely to be 100% irrelevant and be filtered out. (Using the above “free pizza” announcement, if you’re at the Scottsdale Air Park, you really don’t care. But a wine-tasting at a bar near the Air Park would definitely get delivered to you.) So we could broadcast each announcement message to everybody (all current listeners) in real-time (like what Twitter would do) and let the client-side filter out the irrelevant messages (around 99.99%). Or we could reduce that bandwidth by having clients update the server periodically (eg., every 5 minutes) with their location, then for each announcement, a server would locate clients within a reasonable radius based on their last reported position and only notify them directly through a push notification of some sort; the clients would still do some filtering, but this would reduce incoming traffic considerably. I’m not sure which is worse: a server updating a huge number of clients in near real-time, or a huge number of clients updating the server with their geographical location every 5 minutes or so. Or, an alternative is for the clients to poll the server every 15-30 seconds, but this seems even worse in terms of traffic. (Althought this approach is probably ok if we used an existing platform like Twitter.) Any thoughts? -David --------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss
