Personalized Crowdsourcing: Bringing Real-Time Collaboration to Your Social Circle

TL;DR

The shift from anonymous micro-tasks to personalized social help is the core of this research. By engineering a real-time map-sharing framework on Amazon EC2 using XMPP and Long Polling, this project allows users to get trusted, location-aware advice from friends instead of random internet workers.

Background: Beyond the "Stranger" Economy

Most crowdsourcing systems, such as Amazon Mechanical Turk (MTurk), operate on a transactional basis with strangers. This research identifies a major gap: Trust and Personalization. If you want to find a good coffee shop, a friend’s recommendation is worth more than a stranger’s. The author proposes a system that bridges the gap between social networking and real-time utility.

Methodology: The Engineering of Real-Time Sync

The technical challenge lies in the "Push" mechanism. Standard HTTP is request-response based—once the server answers, the connection dies. For a map to update in real-time as a friend draws a marker, the connection must remain "alive."

1. The Long Polling Innovation

To bypass HTTP limitations, the author implemented a threading strategy on Amazon EC2:

• The Android client sends a request.
• The server hashes the thread and puts it to sleep instead of closing it.
• When a state change occurs (e.g., a friend adds a marker), the server wakes the thread and sends the response.
• The client immediately opens a new connection.

2. The Publish/Subscribe Model

The server utilizes the Observer/Observable pattern in Java. Every shared map is an "Observable" object, and every user is an "Observer." This ensures that when one person draws a polyline or marker, every participant receives the KML (Keyhole Markup Language) update instantly.

Figure 1: Real-time marker synchronization: Red markers from the web client appear as black markers on the Android device.

IaaS vs. PaaS: The Sandbox Prison

A key insight from the paper is the critique of Google App Engine (GAE) for real-time applications. GAE is a Platform-as-a-Service (PaaS), which runs applications in a restricted "sandbox."

• The Problem: GAE prohibits system-level calls, preventing the thread manipulation required for custom long polling.
• The Solution: Amazon EC2 (IaaS) was favored because it provides a full Virtual Machine, granting the developer total control over the networking stack and thread lifecycle.

Figure 2: The XMPP bot acts as the bridge, "pinging" friends in the social network via Google Talk to initiate a session.

Experiments & Future Trajectory

The current implementation demonstrates successful bidirectional sync. However, the author notes that "spamming" the entire contact list is a limitation.

Key Takeaways from Ongoing Work:

• Topic-Based Subscription: Future versions will allow users to subscribe to specific "Topics" (e.g., #Shopping, #Toronto).
• Context-Aware Crowdsourcing: Requests will only be sent to friends who are "Online" and interested in the specific geographic area.

Critical Perspective

While the use of XMPP and Long Polling was state-of-the-art during the project's inception, modern developers might look toward WebSockets or gRPC for similar low-latency tasks. However, the author's insight into the social trust factor remains highly relevant. This paper correctly predicted the shift from broad crowdsourcing to "niche," trusted social-assistance networks.

Conclusion: This work serves as a foundational blueprint for hybrid cloud applications, proving that the bottleneck in real-time mobile apps is often the platform's restrictive sandbox rather than the protocol itself.