Meandering around the noosphere I found a link to a post of mine from 1998 on the subject of formalism in the XML specification.
Its a tough one that applies to a lot of technology. On one hand you want smart people to run with their intuitions Ramanujan-style because they will do great things. On the other hand, you need somehow to follow up with the right degree of formalism without adding stop energy into the mix.
In recent times we have seen specs at both extremes - too formal and not formal enough. An exemplar of the middle ground can, I think, be found in Relax NG. All the formalism of a mathematical model with a rigorously specified cognitive escalator into a mere-mortal syntax.
There is great human comfort in the mere-mortal syntax which is a compelling blend of (warning - impossible metaphor ahead) cognitive lube and granite substrate.
Featured Post
These days, I mostly post my tech musings on Linkedin. https://www.linkedin.com/in/seanmcgrath/
Saturday, February 14, 2004
Friday, February 13, 2004
Thursday, February 12, 2004
Web Services Part 1 - Setting Standards
Silicon Republic has an article I contributed to on Web Services and standards. [free subscription required.]
Wednesday, February 11, 2004
Memories of Lua
I came accross History of Lua and it brought back a bunch of memories. I came very close to adopting Lua as my C/C++ extension language of choice way back when. Before Python. Before, even, my 18 month love affair-turned-sour relationship with Perl.
I live, as we say in Ireland "down the country". A common idiom down the country for wanting something real bad is "looing for something". The verb "to loo" is not what you might expect (or fear). It refers to the noise cattle make when they want something. I wanted a dynamic programming capability for runtime configuration of statically compiled C/C++ applications - i was "looing for an embeddable dynamic language" - "looing for lua".
It made me chuckle at the time but hey, I don't get out much.
I live, as we say in Ireland "down the country". A common idiom down the country for wanting something real bad is "looing for something". The verb "to loo" is not what you might expect (or fear). It refers to the noise cattle make when they want something. I wanted a dynamic programming capability for runtime configuration of statically compiled C/C++ applications - i was "looing for an embeddable dynamic language" - "looing for lua".
It made me chuckle at the time but hey, I don't get out much.
Is the net slowing you down? Bandwidth versus latency
An ITWorld article on the distinction between bandwidth and latency and why you should care. Never mind the bandwidth, feel the latency..
Tuesday, February 10, 2004
CWM - a data processor for the semantic web from Tim Berners Lee
HTTP reliability again
Some very interesting comments both on e-mail and on the comment system about Reliable messaging and HTTP.
Mark Baker, Mark Nottingham, John Beatty and Bill de hOra's comments all gravitate around a simple "good enough" solution which I suspect asymtotically approaches Tim Bray's 80/20 point.
Here is where I have ended up. Comments appreciated.
it you wanted a reliable POST operation, for example, to look atomic from the clients perspective then you would need to encapsulate a lump of protocol "dance" code that executes on the client.
If, on the other hand, you work with a simple "pattern" (thanks MarkN), the semantics of RPOST can be achieved with standard GET/POST. In this scenario, the application on the client side needs to know about the little dance. Simplicity of the pattern is thus key lest we create an environment where APIs end up being obligatory.
As I said before, I really worry about introducing APIs into document exchange where an understanding of the bits on the wire is what is really needed. My RPOST atomic operation I fear I may have committed the cardinal sin of promoting an approach which would lead to APIs and a "thickening" and a "magicifying" of the client side which is a bad thing.
Roll on the pattern approach. It would be great to see a generally accepted RESTian approach coalesce to counteract the complexities and panoplies of WS-Reliable Messaging, WS-Reliability, ebMS, HTTPR... (i'm sure I've missed some.).
Mark Baker, Mark Nottingham, John Beatty and Bill de hOra's comments all gravitate around a simple "good enough" solution which I suspect asymtotically approaches Tim Bray's 80/20 point.
Here is where I have ended up. Comments appreciated.
it you wanted a reliable POST operation, for example, to look atomic from the clients perspective then you would need to encapsulate a lump of protocol "dance" code that executes on the client.
If, on the other hand, you work with a simple "pattern" (thanks MarkN), the semantics of RPOST can be achieved with standard GET/POST. In this scenario, the application on the client side needs to know about the little dance. Simplicity of the pattern is thus key lest we create an environment where APIs end up being obligatory.
As I said before, I really worry about introducing APIs into document exchange where an understanding of the bits on the wire is what is really needed. My RPOST atomic operation I fear I may have committed the cardinal sin of promoting an approach which would lead to APIs and a "thickening" and a "magicifying" of the client side which is a bad thing.
Roll on the pattern approach. It would be great to see a generally accepted RESTian approach coalesce to counteract the complexities and panoplies of WS-Reliable Messaging, WS-Reliability, ebMS, HTTPR... (i'm sure I've missed some.).
Monday, February 09, 2004
Mark Nottingham's simple approach to 'reliable POST'
A two phase approach in which the initial server contact results in a unique URI. The client then uses this URI to post the data. This allows the server to easily detect duplicates. Interesting.
Charles Miller on the Java Seige Mentality
"We’re surrounded on all sides, you see. To C programmers, we’re children who can’t handle real complexity. To Smalltalkers and Lispers, we’re misguided souls groping towards a better way, but trapped in the wicked grasp of Sun’s marketing. To Perl and PHP nerds, we’re too busy over-complicating things to ever get anything done. To Ruby and Python hackers, we’re already dinosaurs. And to everyone, we’re apparently the COBOL of the 21st Century." [http://fishbowl.pastiche.org/2004/02/05/the_java_seige_mentality].
I would suggest (and hope) that Java is the assembler of the 21st Century. We know what it does, have confidence that it does it right, but need something more productive for our day job that preserves all our investments.
Patrick Logan on persistence
Patrick Logan talks about persistence and messaging.
HTTP!=REST is an important equation. Unfortunately, it requires familiarity with the RHS as well as the LHS to see why the inequality holds. I hope some day we will get there. Right now, in simple English, here is the problem as I see it:
Developer A: I need process A to talk to process B using internet/intranet protocols. I was thinking of using HTTP PUT or POST
Developer B:That won't work.
Developer A: Why not?
Developer B:Because HTTP is not reliable. What happens if a PUT/POST fails with a timeout? By the time you get the error, it is too late. You don't know if the timeout was a network thing or a process thing. You will end up resending stuff that already got there and not resending that didn't.
If I was you I'd use web services instead.
Developer A: Why?
Developer B: It provides APIs for all that stuff.
Now, I'm in the camp that believes that APIs for this stuff is not the right answer. It blows the non-API everything-is-a-document-dude beauty of, for example, HTTP. It plays directly into the hands of those who would prefer (for a variety of reasons) to re-invent the web rather than use the one we have got for process-to-process integration.
All I want for Christmas is HTTP RPOST and RPUT methods, the return codes of which, tell me whether or not the resource at the end of that URI actually received the POST/PUT.
HTTP!=REST is an important equation. Unfortunately, it requires familiarity with the RHS as well as the LHS to see why the inequality holds. I hope some day we will get there. Right now, in simple English, here is the problem as I see it:
the lack of a simple, reliable messaging mechanism is severly curtailing advancement of the RESTian cause.
Developer A: I need process A to talk to process B using internet/intranet protocols. I was thinking of using HTTP PUT or POST
Developer B:That won't work.
Developer A: Why not?
Developer B:Because HTTP is not reliable. What happens if a PUT/POST fails with a timeout? By the time you get the error, it is too late. You don't know if the timeout was a network thing or a process thing. You will end up resending stuff that already got there and not resending that didn't.
If I was you I'd use web services instead.
Developer A: Why?
Developer B: It provides APIs for all that stuff.
Now, I'm in the camp that believes that APIs for this stuff is not the right answer. It blows the non-API everything-is-a-document-dude beauty of, for example, HTTP. It plays directly into the hands of those who would prefer (for a variety of reasons) to re-invent the web rather than use the one we have got for process-to-process integration.
All I want for Christmas is HTTP RPOST and RPUT methods, the return codes of which, tell me whether or not the resource at the end of that URI actually received the POST/PUT.
Sunday, February 08, 2004
Subscribe to:
Posts (Atom)