Hello all,
I read your paper and I found it very useful. I have a few comments
about
some claims of the paper. I hope you find them useful.
Re-reading what I've written below, it seems to boil down to this:
AtomPub
isn't significantly better than SyncML and is in many ways worse; in
any
case, it seems people greatly prefer JSON over Atom anyway, so why
bother
trying to create a synchronization protocol based on Atom? I guess
that is
basically the conclusion I've come to, which is really unfortunate
for me
since I've spent a significant amount of time writing a bunch of
AtomPub-based software, thinking it was going to be the next best
thing.
Although I focus on the parts of your paper I disagree with, in
general I
think your paper is excellent; I think you guys should share it on the
atom-protocol@xxxxxxx list.
You wrote:
Atompub has already been chosen by various
organizations [8, 9] as the application data
interface of choice
I am not sure OpenSocial is a good example because it mandates Atom
*and*
JSON support, and for all practical purposes most OpenSocial
applications
will choose the JSON since lots of OpenSocial components will be
written in
Javascript. More generally, it seems almost every AtomPub
implementation
provides a JSON interface, but not every JSON server is implementing
AtomPub. It seems we would be better off creating a standard AtomPub-
like
protocol for JSON and skipping over Atom completely.
You wrote:
Moreover, applications are also required to
use a SQL-based programming model to take
advantage of the local storage capabilities
requiring the application to be rewritten
to acquire off-line capabilities.
You guys seem to think that an AtomPub-based offline data storage
system is
better than the SQL-based offline data storage system. I felt the
same way;
I think requiring a client-side SQL database is overkill in the
extreme. I
wanted to suggest an AtomPub-based system as an alternative to the W3C
working group like you guys did. However, even with your approach,
parts of
the application have to be rewritten to acquire off-line
capabilities. As
you wrote:
Another challenge with Atompub [is that] when
data is created off-line, it does not have a
URL, which makes it hard to edit or link to
this data until the server processes the request.
Additional storage and code will be needed for the mapping between
server-generated IDs and client-generated IDs; the SQL-based storage
might
actually be useful for implementing that. Still, I think SQL is
overkill.
You wrote:
SyncML [is] a proprietary synchronization protocol
I think this might be literally true but practically false. SyncML
doesn't
seem proprietary to me. There have been multiple free and open source
implementations of it for years now, and the specifications
themselves are
freely available. It seems that SyncML is as free/proprietary as any
JCP
specification, at least.
You wrote:
SyncML is not suitable for online applications.
I think SyncML is really a superset, by far, of the capabilities of
AtomPub.
It is true that SyncML isn't very HTTP cache friendly, but SyncML-
aware
caches can be used instead (like SOAP). I also wonder if the cost of
the
server-stored client state is a big deal; it seems like SyncML has a
few
features to limit the cost of this. SyncML is *very* widely deployed
and has
lots of standard features that are unlikely to be standardized for
AtomPub
implementations any time soon (e.g. standard processing of email and
other
types of objects; standard search interface)
The main issues with SyncML seems to be its complexity and
interoperability
issues with the various implementations. But, AtomPub gets rid of the
complexity by leaving things unspecified, and consequently it is less
interoperable than SyncML. It seems that AtomPub has actually
evolved into a
framework for proprietary, un-interoperable protocols; e.g. GData,
Astoria,
and Nokia Lifeblog are all AtomPub implementations; but, even
ignoring the
fact that they implement different versions of the protocol, they
are still
completely un-interoperable, more-or-less.
Your summary of AtomPub limitations was the best that I've seen so
far.
However, you didn't mention that AtomPub has a N+1 GET problem
analogous to
the common OR-mapping N+1 SELECT problem; once you have downloaded a
feed,
you still have to GET each entry you want, since the feed contains
only a
subset of the content of each entry. This is a problem that doesn't
occur in
SyncML.
Regards,
Brian