![](bg4.png)
Figure 2: Synchronization via a public tweet.
back-office, over which tweets will then be streamed
incrementally. In combination with extensive filter-
ing mechanisms (hashtag-based, for example), appli-
cations in this way obtain near-real-time access to ex-
actly the type of tweets they are interested in.
In the Twitter-mediated synchronization model,
the content synchronization data is exchanged as pub-
lic tweets (see Figure 2). These tweets are published
on the Twitter account of the user who altered the state
of the sMS session and they include a specific hashtag
(#syncMedSha) as well as an ID that uniquely deter-
mines the relevant session. A PHP daemon running
on a back-end webserver leverages the Streaming API
to filter all the tweets that transport synchronization
records, parses them, and persists the extracted syn-
chronization instructions in a local RDBMS. Clients
iteratively query this database (by issuing an AJAX
request to a server-side PHP script) to retrieve the up-
to-date state of the sMS session in which they are cur-
rently engaged. Note that, as opposed to the Facebook
scheme described in Section 2.4, nonsensical mes-
sages (from a human perspective) are in this solution
actually being introduced in the user’s tweets list. To
minimize the potential detrimental effects of this ap-
proach, a background client-side thread exploits the
Twitter REST API to delete synchronization-related
tweets that were previously issued by the local user
and that have become obsolete.
Besides being less elegant than the Facebook im-
plementation (due to the use of public and personal
tweets to communicate synchronization instructions),
the Twitter-powered synchronization method faces a
number of constraints that are dictated by Twitter
and that render the solution to be suboptimal at best.
First, tweet length restrictions limit the potential pay-
load volume of synchronization messages. Secondly,
Twitter explicitly advises not to access the Streaming
API from within Web browsers given their Same Ori-
gin Policy with respect to the execution of JavaScript
code. As a result, a substantial financial overhead
is incurred due to the necessity to deploy a server-
side component (see also Section 3). To aggravate
matters, unnecessary additional delay is introduced.
Third, like Facebook, Twitter imposes rate limits on
the usage of its APIs and enforces restrictions to
ensure fairness among users and to protect the ser-
vice from downtime due to overload. Contrary to
Facebook however, these usage restrictions are well-
documented. This implies that a strict per-day upper
bound is set on the number of synchronization mes-
sages that a user will be able to disseminate. Finally,
again analogous to the Facebook implementation, the
publication of synchronization data tends to be slow,
as the posting of tweets via the Twitter REST API is
typically non-instantaneous.
3 COST ANALYSIS
Section 2 has indicated that substantial differences
exist between the five solutions in terms of syn-
chronization efficiency and performance. Now, we
will take a high-level look at the financial repercus-
sions that are associated with the adoption of each of
the approaches. Commercial applications might rate
cost-effective deployment and maintenance models
equally important to synchronization performance.
Table 1 summarizes the economic implications
due to infrastructural requirements for each of the de-
scribed synchronization solutions. Three out of the
five schemes can be rolled out without incurring any
back-end hardware deployment cost. Of these three
technologies, XMPP MUC and Facebook are further
characterized by the complete absence of operational
or maintenance-related expenses, which makes them
particularly attractive. The same is also true for the
third solution, Synchronization in the Cloud, given
that the distributed groupware service does not violate
the resource quota of the PaaS provider’s zero-cost
policy. Typically, these quota suffice for a Proof-of-
Concept deployment, and often even for a small-scale
commercial installation of the service.
When collating the Webserver plus AJAX and the
Synchronization in the Cloud solutions, the latter will
typically outperform the former in terms of financial
efficiency, even if the involved synchronous applica-
tion would exceed the resource quota associated with
the PaaS vendor’s cost-free pricing model. Many
cloud platforms leverage a pay-per-use billing sys-
tem, whereas traditional webserver hosting typically
imposes a monolithic monthly or yearly fee. This im-
plies that cloud-based solutions in most cases will ex-
hibit a much more favourable cost-benefit trade-off.
Finally, although the Facebook-mediated synchro-
nization scheme scores highly in the bird’s-eye cost-
benefit analysis, one must keep in mind the practical
limitations that are entailed by this approach. A de-
veloper who opts to host his application on Facebook
is completely dependent on Facebook’s hardware in-
frastructure. In this context, no guarantees are given
in terms of performance, as there is no notion of Ser-
WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies
152