links for 2007-09-30
short version: LAMP
"What about if I PUT X and then DELETE X? Am I guaranteed that these operations will be performed in the correct order? (i.e., am I guaranteed that the object will eventually be deleted?) "
Asked in the context of S3. An earlier answer indicated that two PUTs could arrive out of order given the right sequence of partial failures. Since the network isn't smart (a good thing), it treats all HTTP methods equally, so the answer is you're not guaranteed to not get PUT/DELETES out of order; albeit it's unlikely to happen.
Ian Davis is right; it's tricky to explain or justify this to devs who have grown up on strong consistency, or even things like the JVM's "happens-before" semantics. The way I look at it is that compensating action or dealing with out of order events is kind of like dealing with domain business "logic", insofar as there is that real world messiness to contend with. But to work at bigger scales, if you want availability, consistency has to give, as partitioning will tend to happen.
"Mapping a message broker to REST and AtomPub turns out to be much harder than it looks."
I've held this position for years; and its more general than Atompub - the mismatch is with HTTP. I'm on the thread that James links to, but I'm fairly sure we talked about this a few years ago. You might have to go and build this out to see the impedance between a HTTP resource and a queue, but it's there. That impedance is one reason why the "feed" data structure, be it RSS or Atom has come to exist. Let's switch protocols. If you were to run a messaging service over XMPP, you'd find yourself dropping the feed structure as redundant and just slinging the entries.
I don't work on this kind of thing these days but the problem is still interesting. The secret to getting it done is to make sure the message exchange is a different resource to both the queue and the exchanged message. That's why HTTPLR is the way it is (I'm chuffed the ActiveMQ page on restful queues has a link to it).
At a quick glance I suspect the ActiveMQ guys are more or less there; I'd to see it explicit that the collection issues URLs for the exchanges and not the actual message content (this makes tracking easier). Messaging is a big deal and having something run over Atompub would justify an RFC.
What are you, the consumer, trying to accomplish? You want to be notified when something happens. We have a well-known pattern for that problem. It's called publish-subscribe. The publisher keeps a pointer to the subscriber, and when something happens tells the subscriber about it. Maximally efficient.
Why doesn't it work? Because the internet is anonymous. People can behave badly because nobody knows who they really are, and enough people do behave badly that you can't risk giving out a pointer to yourself. So we don't. Instead, we need RSS where our readers are constantly, stupidly asking, "did it change yet?" "Did it change yet?" "Now has it changed?" "Now?""
This is a really dumb solution, but it's the only way we can retain our privacy, because if we give out anything that can lead back to us then someone will use it to annoy or trick us.
RSS syndication being pull based has *nothing* to do with preserving anonymity. PubSub syndication doesn't work because the Web architecture is constrained against server-client communications. Along with other critical details like firewalls and NAT.
updated: strike that, Chris Messina set me a mail; No Atompub for MarsEdit yet :)
Still waiting on Facebook and MySpace ;)