See: AtomPub Multipart Media Resource Creation! Basically how to do SwA or MTOM type stuff with Atom.
Ah Tim, better start printing these out so that you can count the pages when REST-* is all said and done.
Sigh. Its really too bad that we are now going to re-invent it all around Atom.
3 comments:
Heh, I'll take that page-count bet.
As regards re-inventing it all, it's possible this shows the importance of process; if the WS-* project had had an an IETF-like ultra-transparent process, the outcome might have been better. But we'll never know.
BTW, this isn't like MTOM at all, I don't think. MTOM tries to stretch an XML Infoset over your MIME package, while Joe's proposal just says "Send two things at once, use standard multipart packaging, and here's how you deal with them."
Tim's right. MTOM tries to reinvent existing standards (like MIME) with an XML-based syntax. As if being XML wins us anything. That's what WS-* is all about, really. Reinventing existing technology, only wrapping everything in angle brackets. Plus serving those angle brackets in the least optimal way through a pseudo neutral transport protocol (which always is HTTP). How is that better?
Come on Tim you of course know that MTOM was after having done SOAP with Attachments (SwA) .. and this is exactly the same as SwA except for Atom - AwA :). That's a perfectly fine path to take - and in case you didn't know, there were very good reasons to go to MTOM: basically to be able to sign and secure the message as a single entity, even if it had attachments.
@asbjornu: MTOM was not a reinvention of MIME (and if you want to find a reinvention then point to DIME) - it was a mechanism invented to make it possible to secure an entire message as a single thing.
If Atom ever has a feed signing thing then the problem will hit Atom too.
Anyway, Tim, I'll buy you a beer (in Sri Lanka if you'd like to visit!) if in 2 years from now we're not looking at a bunch more REST-* specs :).
Post a Comment