• My wife loves me. I’m a very lucky man.
• I’m starting to really dig Safari Books Online. Having a tablet really helps here, I can sit in bed and read and it’s ALMOST like reading a real book. Is there an offline experience? Something like the NYTimes WPF Reader app would be killer.
• I’m not a Twitter guy, but I like the idea of using it to publish CI results. Not quite as cool as using the Ambient Orb, but close. (via DotNetKicks)
• Soma details the dogfood usage of TFS in Developer Division. Sorta interesting if you’re into knowing that stuff. Brian Harry apparently has much more.
• I realize that linking to Pat Helland every time he writes something is fairly redundant. If you want his feed, you know where to find it. But he writes great stuff! The latest is Accountants Don’t Use Erasers, which talks about append-only computing. His point that the database is a cache of the transaction log is mind blowing, yet makes total sense.
• Bruce Payette blogs a PS DSL for creating XML documents.
• Jesus Rodriguez details WCF’s new Durable Service support in .NET 3.5. I get the need for the [DurableServiceBehavior] attribute, but do I really have to adorn each of the service methods with [DurableOperationBehavior] too? That seems redundant. Also, I wonder how this looks at the channel layer?
• Speaking of WCF’s channel layer, I recently picked up a copy of Inside Windows Communication Foundation by Justin Smith. This is the first book I’ve found that has more coverage of the channel layer than the service layer, so I like it.
• Dare writes about Web3S, Windows Live’s general purpose REST protocol. Apparently, WL started with Atom Publishing Protocol, but found that it didn’t meet their needs around hierarchy and granular updates. David Ing says it’s “not that similar” to my concept of REST, but I going to read the spec before I comment.
• Scott Hanselman writes about how he learned to program and some thoughts about teaching his son. Patrick has recently started expressing interest in programming (he want’s to do what Daddy does). At four, I’m thinking I’ll start him on Scratch (though ToonTalk looks interesting). As he gets older, I was thinking about Squeak, though I’m a smalltalk noob. I really like Scott’s idea of creating a connection to the physical world via something like Mindstorms. Patrick loves Lego almost as much as his dad, so that would be cool.

Last week, I asked a REST Question: is it still REST if you don’t use HTTP? My interest in durable messaging is well documented, so I want is to see a RESTful approach combined with a durable messaging. We all know my durable messaging tool of choice, though I’d trade SSB in a second for something that provided durable duplex messaging in a standard way.

Anyway, there were some fairly interesting responses that I wanted to highlight.

Probably most interesting to the discussion at hand was John Heintz‘ comment pointing out the existence of “Waka” ,  a new transfer protocol to replace HTTP from Roy Fielding. The fact that Dr. REST is working on a new protocol that’s designed to be more RESTful than HTTP should put to bed any REST “is and only is” HTTP arguments.

Erik Johnson agrees that you can separate REST and HTTP, but he thinks I ought to call it something else. He suggests “resource-oriented” – have we created a new TLA here? Are you down with ROA, ROAD, ROD, ROP and all the other acronyms we could spawn?

Nick Malik breaks out the IFaP acronym – Identifier, Format, Protocol – and points out “Each of the successful Internet standards, from HTTP to SMTP, has an IFaP at the heart of it.” But does anyone think SMTP is RESTful? I don’t. I think standardization of IFaP’s is on par in importance with RESTfulness, but they’re orthogonal. That is to say I think Nick’s wrong – I’m guessing we’ll go a few rounds on this when he gets back from Nashville – or should I say, if he gets back? 😄

Arnon Rotem-Gal-Oz has been wondering about REST without HTTP the same way I have, but he doesn’t really go into detail as to why. I want durable messaging, Arnon mentions something about topic hierarchies. Couldn’t you do that with HTTP, Arnon? He also points out a new DDJ article on REST. It’s good, if high-level overview-y.

Pat Helland writes that Every Noun Can be Verbed. It’s more related to CRUD is CRAP than REST == HTTP, but it’s well worth the read. His point about using filling out a form being CRUD, but then handing the form over to someone else being an invocation of behavior is fairly eye-opening. As long as you “interpret the durn’ things with the correct semantics”, it doesn’t really matter if they’re nouns or verbs.

Last but not least, Ted Neward and Adrian Trenaman discuss SOAP vs. POX over on The Server Side. They focus too much on SOAP encoding (isn’t that dead yet?), but near the end Ted points out: “Problem is, REST assumes that you want to carry all of the state in the payload itself, and for a modern enterprise system, or, hell, even for a game, that’s not always a safe assumption.” Doesn’t address my questions about using REST without HTTP, but a very good point nonetheless.

Since there appears to be at least a handful of RESTifarians among my readership, I’m just going to throw this half-formed thought / almost question out there. Maybe it’s a FAQ, in which case I’d appreciate a pointer in the right direction.

My observations about REST are:

1. REST is a an “architectural style for distributed hypermedia systems“.
2. REST “has been used to guide the design and development” of HTTP and URI.
3. Therefore REST as an architectural style is independent of HTTP and URI.
4. Yet, I get the feeling that the REST community would consider a solution that uses the REST architectural style but not HTTP and/or URI as “not RESTful”.

Am I wrong in observation #4 above? If you’re addressing resources by resource identifiers [aka URIs] but transferring those resource representations over a durable duplex protocol [aka not HTTP], are you still RESTing?

(Note, such a RESTful durable duplex protocol doesn’t exist to my knowledge, though I would be very happy to be wrong about that. SSB does durable duplex, but it doesn’t support URI style resource addressing. Granted, if I was going to build a durable duplex RESTful protocol, I would build on SSB – much the same way that HTTP builds on TCP. Though I am a huge fan of SSB, I’m specifically not suggesting that SSB is RESTful.)

FYI, I’m at TechEd all next week. Given that WiFi access at conferences usually blows, I’m not planning on regular morning coffee posts. I’ve asked Dale again to keep the lights on around here and he’s graciously said yes. Since I’m not on vacation, I’ll be lurking around as well, but I’ll be in an out. See you in Orlando!

• Jeff Atwood proclaims that developers are their own worst enemy, because they write too much code. Add in a pinch of “not invented here” syndrome and I think you’ve got it. This is one of the reasons why people think Ruby is the tits.
• Scott Hanselman has already taken advantage of the new WLWriter provider customization API.
• Erik Johnson writes about the thunderous REST bandwagon. He doesn’t explicitly say it, but my take is that he thinks this all ends up in some middle ground between REST and WS-*. I hear that, at least, if that’s what he’s saying. I’m not sold on “HTTP is all you need” – I need durability and async messaging, but I don’t see how to get there from here with just HTTP.

• Google announces Gears, a browser plugin for taking your web application offline. Developer docs are also available. TechMeme has lots more, but obviously this is yet another significant bow shot in the upcoming unified client platform war. By my count, there are four horses in this race: Microsoft with .NET and Silverlight, Adobe with Flash and Apollo, Google with AJAX and Gears and Sun with Java and JavaFX. Did I miss anyone? (via Dare Obasanjo and Scott Hanselman)
• Alex James writes that REST is about intent and shows a pseudo-code sample posting multiple changes to a single endpoint as a way of demonstrating your intent that they be applied atomically. Andres Aguiar left a comment saying that Astoria does something similar. Personally, I like that model for transactions better than the transaction factory approach Jon Udell describes. But either way, you’ve moved beyond simple CRUD style services and into the world of protocol. Surfacing intent via protocol aligns with what Tim described as making the protocol explicit
• Windows Live posted new beta versions of Writer, Mail and Messenger. I’ve been on an internal build of the new Writer for a while and I’ve really been impressed. There’s also a new Provider Customization API, so I can’t wait to see what the DasBlog folks do with that.
• Scott Guthrie’s LINQ series continues, this time covering how to build the LINQ to SQL data model. Looks like they used the DSL toolkit to build the LINQ to SQL data model designer, cool!
• Martin Fowler digs intoracc, a yacc-esque compiler compiler for Ruby. Looks interesting as a internal DSL example (better than the now-canonical rake example). But why is the sexy new language on the block using old school CFG’s instead of new hotness PEG’s?
• Speaking of Martin, he writes about the opportunity Ruby presents to Microsoft, building on Scott Hanselman’s concerns that Microsoft is losing the Alpha Geeks. Sam Gentile also weighs in, suggesting that Microsoft is at the crossroads. Frankly, I don’t work in evangelism anymore so I’m going pass these links along without comment except to say that Scott, Martin and Sam are all folks I have much much respect for.