More on SSE
I wanted to take the time in this post to answer some of the comments left on Jack’s introductory post. And I also want to remind everyone that the FEED-TECH mailing list is starting to get some good activity. If you haven’t already, please subscribe to the list: Send email to: listserv@discuss.microsoft.com with the message body “subscribe feed-tech” or use the web-based subscription form.
Neil MacLean writes:
This seems really exciting but to help me get my (not so technical) brain round the potential for SSE could you give some practical examples of how you could see it working, for example, in the travel business?
Neil obviously knows more about the travel business than I do, so all I can do is talk about SSE: The interesting bit about SSE is that it allows two-way, multi-master replication. By that I mean:
- “Two-way” in the sense that I can modify other people’s items (and they can modify my items).
- “Multi-master” in the sense that no one place holds the “truth”. The data exists on multiple places (servers); I can change it in one place and it will replicate to the others.
Applying this to the travel industry, I would say that we should avoid scenarios that just deal with notification. Scenarios where you just need to be informed of changes to a schedule (or whatever) can probably be done with just plain RSS.
But imagine a scenario where you are creating an itinerary with a travel agent (or with your spouse or friends or whatever). You might both want to be able to edit the itinerary. For example, you might create the initial calendar entries for when you want to travel. The travel agent might edit those entries to include the exact date. You might then add entries for specific tours that you might want to take. The travel agent could then edit those entries to include additional information (time/place, reservation info, etc.)
Even better, because SSE is “multi-master” you can have a copy of the itinerary both on the travel agency server and on your laptop. You can always view your itinerary (and even make changes) on your laptop even if you’re not online. When you finally get an internet connection, your laptop can automatically synchronize with the travel agency server.
Hopefully that will give people some ideas.
Lee, Hae-Seok writes:
What's difference between SSE and SyncML?
I can only quote from the FAQ, which contains this entry precisely to answer this question:
When should I use SSE as opposed to some other synchronization technology?
“SSE is ideal for replicating data that can be published in an RSS feed. That includes lists of items such as calendar appointments, contacts, favorites, and news items. In addition, SSE is ideal for bidirectional, asynchronous replication, particularly for scenarios where multiple people can edit or create entries.
Like RSS, SSE was designed with simplicity in mind, and developers will find that implementing SSE replication is easy, especially for an application that already supports RSS.”
Tony Perrie writes:
It seems that in a star topology, SSE would somewhat approximate what Exchange and Lotus Notes seem to accomplish as pertains to scheduling. If you used SSE in a mesh configuration, it would seem to require a peer-to-peer protocol to negotiate communication between links that use network address translation. Would Avalanche technology or another companion technology be used to negotiate mesh networked nodes?
This is very perceptive, since SSE makes the most sense in a mesh configuration (in a star topology, you only need replication for offline usage). I know this sounds like I’m side-stepping the issue, but the important thing to remember is that SSE is not a protocol. As Tony points out in the rest of his post, SSE is just a data format that can be used over any protocol.
You can even imagine coming up with some protocol using XMLRPC or SOAP where the “subscriber” passes additional information to the publisher so that the publisher can send down only the information that the subscriber needs (again, this is something that Tony suggests). So perhaps people might wonder, why didn’t we specify some kind of protocol like this in the spec? The answer is that the chance of a standard being adopted is inversely proportional to its complexity. If we had specified a peer-to-peer protocol in addition to a replication format, we would have decreased our chances for adoption. Instead, we chose to make SSE “composable”, meaning that no matter what p2p protocol your app uses, you can use SSE with it.
Thanks for everyone for your comments, and once again, please subscribe to the FEED-TECH mailing list if you are interested in an ongoing conversation.
-- George Moromisato