-
“Globally distributed SOA seems to be looming out of the mist, and it is a different shape to what was envisioned a few years back.” Envisioned by some perhaps 8-)
-
“Me, I blame WSDL and XSD”. Amen. Both of those encourage practices which are actively harmful to integration; WSDL encourages services to have different interfaces, and XSD limits extensibility (unless you really know what you’re doing).
-
“You can do a lot with collections + CRUD” 8-)
-
“We will have succeeded when no one cares”
-
“The Evans Data survey found a 37% increase in respondents implementing or considering REST, with one out of four surveyed saying that they are considering REST-Based Web Services as a simpler alternative to SOAP-based services.”
-
Norm finally picks a side… the right one, as it turns out 8-)
-
SOAPHttpRequest?! *groan*
-
… and shows a lack of understanding of REST and Web style services. Sounds like they could do with another co-CTO (Tim?) 8-)
-
“I suggest they roll some heads and figure out a real product strategy” Heh. Who couldn’t see that one coming? If I were them, I’d be be giving AOL a call.
-
“RDF categorically *does not solve* this problem. It *mitigates* it, on the belief that we will tend to see less model theories than formats flying around.”. Heh, +1. Of course, I think we will see less model theories.
I was looking through the scriptaculous drag-and-drop pages tonight, and stumbled upon this markup/script snippet;
<div id="photo1"> <img ... /> </div> <script type="text/javascript" language="javascript"> new Draggable('photo1',{revert:true}); </script>
Isn’t that just screaming out for declarative Javascript?
So I quickly hacked together a teeny tiny script to present the Javascript API via a declarative interface. See it in action for yourself (Firefox only). The markup for that script above would be, simply;
<draggable id="photo1" revert="true"> <img src="..." /> </draggable>
I’ve just got drag working right now. Drop will be a little trickier, because I’ve got to decide whether I want to setup something like an “onDrop” handler (pro: powerful, con: powerful), or whether I can define some canned droppable types, like a shopping cart, or a file uploader, etc.. Perhaps both?
An important, nay, foundational part of my mental model for how Internet scale systems work (and many other things, in fact), is that I view standards as axioms.
In linear algebra, there’s the concept of span, which is, effectively, a function that takes a set of vectors as input, and yields the vector space spanned by those vectors; the set of all reachable points. Also, for any given vector space you can find a set of axioms – a minimal set of vectors which are linearly independent of each other (orthogonal), but still span the space (note; I use “axioms” here to refer to a normalized set of basis vectors).
So given, say, HTTP and URIs as axioms (because they’re independent), I can picture the space reachable using those axioms, which is the set of all tasks that can be coordinated without any additional (beyond the axioms) a priori agreement; in this case, the ability to exchange data between untrusted parties over the Internet. I can also easily add other axioms to the fold and envision how the space expands, so I can understand what adding the new axiom buys me. For example, I can understand what adding RDF to the Web gives me.
More interestingly (though far more difficult – entropy sucks), I can work backwards by imagining how I want the space to look, then figure out what axiom – what new pervasively deployed standard – would give me the desired result.
As mentioned, I try to evaluate many things this way, and at least where I know enough to be able to (even roughly) identify the axioms. It’s why Web services first set off my bunk-o-meter, because treating HTTP as a transport protocol is akin to replacing my HTTP axiom with a TCP axiom, which severely shrinks the set of possible things that can be coordinated … to the empty set, in fact. Oops!
See also; mu, the Stack, Alexander, software architecture.
-
“The biggest threat to Google isn’t that someone else will implement the same Calendar API as Google, it’s that someone will make web pages uncrawlable through proprietary extensions to HTML or HTTP”