" /> Bill de hÓra: July 2003 Archives

« June 2003 | Main | August 2003 »

July 31, 2003

HTML subsets HTTP, breaks web architecture, movie at 11

You can't use PUT or DELETE in a HTML form.

Until recently I thought this was because no-one had bothered to build those calls it into a browser engine. But no:

The method attribute of the FORM element specifies the HTTP method used to send the form to the processing agent. This attribute may take two values:

* get: With the HTTP "get" method, the form data set is appended to the URI specified by the action attribute (with a question-mark ("?") as separator) and this new URI is sent to the processing agent.

* post: With the HTTP "post" method, the form data set is included in the body of the form and sent to the processing agent.
[17.13 Form submission]

What on earth were they thinking?

I used to wonder why web services were so enamoured with POST. Now I know. If web services is anything down in the trenches , then it's the descendent of CGI and form upload. Of course you'd think POST was all there was if all you were ever allowed to do was POST.

So, HTML subsets HTTP. If any other technology did that, there'd be uproar. Yet I don't think the W3C Technical Architecture Group have even discussed this. Why does it break web architecture? Well, instead of using PUT/POST/DELETE in a form against a single resource/URI, I either have to use multiple URIS to operate on a single resource, or I have to tunnel the PUT/DELETE actions though the entity. And all those log out links that act via GET. Truly, deeply, absymal.

July 30, 2003

Martin Fowler: MultipleCanonicalModels and messaging integration

MF Bliki: MultipleCanonicalModels

One of the interesting consequences of a messaging based approach to integration is that there is no longer a need for a single conceptual model to underpin the integration effort.

Exactly! At Propylon we've been building messaging solutions combined with data and domain model transformations for our customers for a few years now, with great success*. It's unquestionably the way forward when you combine it with XML document payloads - technology that offers genuine value while preserving existing investments. No more rip and replace as our CTO, Sean, likes to say. Which is why the web services world are in the process doing a 180 from RPC to Doc/Lit - they got it so very wrong.

These days many integration groups question the shared database approach, instead preferring a messaging based approach to integration. I tend to agree with this view, on the basis that while it's not the best approach in theory, it better recognizes the practical problems of integration - especially the political problems.

I understand the lure of the one true model, and if you know anyone that still believes in it, you could do no better than give them a copy of Bill Kent's classic Data and Reality. But in this case, messaging is the best theoretical approach that also happens to be the best practical approach. Such beasts are sadly rarer than they should be in IT.

Who knows, maybe Martin will write the book on message based integration as he has for n-tiered architectures.

[Sean and Fergal have written a whitepaper that explains the value of the messaging approach: Principles of Service Oriented Integration].

A fix for Cygwin and CVS linefeeds

Here's something that came up in work, and a workaround.

If you check in a file with dos line endings (\\r\\n) from the given Cygwin CVS client, it will not convert the dos line feed to Unix (\\n). That means the file is stored in the repository with bad line endings which hurts both CVS diffing and possibly any non Windows users.

I suspect this is because the CVS cygwin client has no idea it's running on Windows (that's strong encapsulation for you) and assumes no conversion is neccessary. In any case it's not what you want to happen.

To get around this in a way that will let use a command interface to CVS, you need to do two things:

  1. Install WinCVS if haven't already and add it's command line client, cvs,exe, to your PATH. For example, mine is in E:\gnu\WinCvs 1.3\CVSNT.
  2. Uninstall the CVS client from Cygwin. Cygwin seems to pick up its own CVS first regardless of how you organize your Windows path. Do this this through Cygwin's setup.exe.

To test you're using the right client for your OS, fire up a bash shell and type

  cvs -version | grep CVSNT

you should see a match, something like this:

  Concurrent Versions System (CVSNT) 2.0.2 (client/server)
  CVSNT version (Apr 16 2003) Copyright (c) 1999-2003 Tony Hoyle and others

Later: from Matt Quail:

We have this problem too. But I've had cygwin-CVS work fine for me now so long as I do either of the following:

  1. store .java files in the file system using DOS line endings, and have my drives mounted textmode
  2. store the .java files in the file system using UNIX line endings, and have my drives mounted binmode.

see the cygwin "mount" command for mount modes, mine are:

  c: on /cygdrive/c type user (binmode,noumount)
  d: on /cygdrive/d type user (binmode,noumount)

And if the files on a particular disk get wonky, I just run "dos2unix" :D

JXTA v Jabber continued

I got a comment from Bo about JXTA v Jabber, that's well worth lifting:

As I see it, Jabber is still a largely unproven protocol. Sure there are deployments but I've never heard of any massive Jabber installations with one server handling thousands of clients. And due to several fundamental design problems in Jabber (eg the persistent connections/xml-streams architecture) I don't think this will ever happen. JXTA is alive and well, it just hasn't reached the marketing phase. Rest assured there are real corporations building real solutions on JXTA--some internal, some for sale. Also, you might look closer at the JXTA architecture. It isn't really an architecture of architectures at all. The best analogy of JXTA is a TCP/Protocol Stack for P2P applications and indeed there's been complains that JXTA is too low level. Anyways, personally, I expect big things from JXTA but as always, we'll see what happens.

To which I'll say two things.

At 10 million users, Jabber is proven in my book. I'm not sure about one server serving thousands of users, because I'm not sure that's what you'd want to do with it, or any messaging/p2p system.

My concern with JXTA remains, because I'm not sure it will get the marketing. Who will market it? Not Sun, at least not heavily enough. Not MS. Not SAP. IBM could, but they're heavily focused on Grid computing. The only vendor with clut that could be interested in selling P2P marketing is Intel. So I think for JXTA to succeed it has to do so via network effects, ie it will have to succeed the way TCP/IP, email, the web, and to a lesser extent, Jabber did.

21st Century VAX

ACM Queue - A Conversation with Jim Gray

What do you do with a 200-gig disk drive? You treat a lot of it as tape. You use it for snapshots, write-anywhere file systems, log-structured file systems, or you just zone frequent stuff in one area and try to waste the other 190 GB in useful ways. Of course, we could put the Library of Congress holdings on it or 10,000 movies, or waste it in some other way. I am sure that people will find creative ways to use all this capacity, but right now we do not have a clear application in mind. Not many of us know what to do with 1,000 20-terabyte drives.

I know what you do. When you have a 200Gb drive you stop cleaning out your 40Gb drive. Nothing gets deleted anymore, because there's no need (for a while).

This could change lots of things. Like files. Files on your computer are the way they are because they were designed to be space optimal. That's why you can delete them, compress them, move them, defragment them, change them, destroy them. Think of all the OS technology and software applications built on the assumption that files are digital plasticine. It's all the OS technology and software applications. Now imagine a file system where you never deleted anything, where every write was a new version linked to the past version, where a file was really the name of a tree of files.

[Bill Grosso: We're all Gelernter now]

July 29, 2003

3 more WS-* specs

WS-CAF Announcement

Coordination, contexts, transactions.

Funny. The development world can't move fast enough to agile methods, while the vendors are producing documents to beat the band.

None of this stuff went through the JCP. I wonder why not.

July 28, 2003

The AtomAPI: NothingElseReallyMatters

The AtomAPI

This document may be the single technical advance resulting from *echo - it might be all worthwhile yet if this gets deployed. Nice one Joe.

[Ken McLeod's proposal]
[Tim Bray's proposal]

July 27, 2003

Real world application for RDF, and the quote of the week

ideas asylum

When was the last time you were at a meeting and were trying to reschedule the next one? Each person calls out suggestions based on their own calendar and everyone else checks that date, someone inevitably rejects it and the cycles starts over. Soon your come to the conclusion that there is no perfect date so a compromise is sought. Why isn't this sorted out by now? Why don't we have diaries which can negociate with each other? We don't even have the ability to discover which days have the least collisions?

This has been taken on a few times by the RDF community, it's always been a contender for RDF's killer app. I definitely remember Dan Connolly hacking something like this for Palm but a quick search doesn't show any links. Libby Miller was also working on this at some point (with iCal?). Danny or Shelley might know what's going on with that all things calendrical in RDF today, but essentially I believe the guts of the data models are there, albeit complicated (it's hard to conclude that PIM vendors want interop). What's left is a small matter of programming - scripting solvers for the PDAs.

Quote of the week from Jamie:

Information doesn't flow, its pumped.

Yes. Via transformations!!

JXTA v Jabber - Jabber wins?

ideas asylum

Jamie Lawrence:

Jabber has lots of interesting features for instant messaging like "presence" (which JXTA is only just getting around to) and even "mood indicators". But overall, JXTA has a nicer architecture which would seem more appropriate to building applications on top of. JXME also has the advantage of being smaller (~10k[pdf] vs 50k?). And apparently Sun are beginning to think of JXTA as something other than a toy research project. On the other hand, Jabber clients already exist for J2ME whereas I'm not aware of anything based on JXME.

I wonder is Sun really taking JXTA seriously? JXTA reminds me of Jini, a very decent technology allowed to wander somewhat aimlessly - and so everyone behind the firewall got EJB, when they could have had JavaSpaces. I remember a Sun engineer explaining to me a few years ago how the Webservices/SOAP had thrown a disruptive (and suboptimal) spanner in the technology adoption curve - the next wave after client server should have been mobile, peer aware, seamless networking, and Jini based, but it turned out to be RPC with angle brackets. Who'd have thought it?

Personally, I'd graft the best of JXTA onto Jabber, if Jabber suits. J2ME device footprints will catch up. [The J2ME community could learn something from the history of PC gaming, namely use the sofware to drive the hardware, not the other way around - consider what's being done to XML and SAX on J2ME.]

I have two other minor beefen with JXTA.

First is that it reminds me of other mildly chaotic opensource projects. The ones where there's way too much going on to get a handle on.

The second is architectural rather than social. I've only goofed about with JXTA, and I basically like it but it strikes me as having framework disease. It's an architecture for architecting p2p architectures. Sometimes its worth solving the problem before tackling the meta-problem.

Trang Ant task v0.8

Is here. It's a refactoring/bugfixing release, there are no changes to the task interface.

The next release should support filesets/directories as input.

My personal practices map

JSPWiki: PersonalPracticesMap

In your own time, make a list of your 10 most important practices for coding and design.

Good idea, here's mine:

  • Unit testing (test first)
  • Always be cleaning (avoid broken windows)
  • Eliminate duplication (don't repeat yourself)
  • Seek fast feedback (early and always, rollback in doubt)
  • Refactoring
  • Ask for help (communication)
  • Use many environments

I don't have ten (ten would be too many). But those seven have improved my code more than anything else.

The first three - I don't program too well without them.

As a theme the fourth is most important - take a small step, checkpoint against reality, take the next step. A good version control system helps bootstraps this (and keep a long undo buffer). You also need to inculcate some discipline to work this way - hard work if you're naturally disorganized (as I am, and I do slip). Refactoring is the grammar for a process based on fast feedback. Take those five together and you have a reinforcing and powerful set of practices for better software. Some implicit byproducts are, a separation of concerns, pushing for orthogonality, a clear statment of dependencies, an evolving architecture and a regression test suite. I'm sure there are others. There are two things you get that stand out for me, one micro, one macro. First, the ability to backtrack on changes; it's hard to spin out of control and accumulate bad decisions in this way. When I insist on going Only Forward is when the code gets out of control. The second is an ability to change and adapt the code even as the codebase grows in size and functionality - vital for both your sanity and the economic health of the business. So much code rots and is thrown away because it can't be changed as the world around it changes. What a waste.

And the good news - the rise and rise of the agile movement is going to make these practices as common as muck.

Asking for help is obvious, but programmer culture is so steeped in the fear of seeming stupid it's often a problem (even to be asked). If your shop has this fear, your have a problem no process alone can help with. I've worked any of number of jobs outside IT and I swear I've never seen anything like the faux-machismo that infects developers - builders and bouncers are far better communicators.

The last is maybe the oddest - but it seems the more environments I work the code in, the more robust it tends to be. I think it's a kind of a non-functional acceptance testing that drives out system level bugs, or if you like, exposes the Big Lies.

There are other specifics for Java that have helped me enormously, mostly around organizing projects. I'll write them down soon.

July 26, 2003

Adam Bosworth's blog

Adam Bosworth's Weblog: Ruminations

Cool. First time I've seen a HTTPS trackback too.

London foxes

A Corporate Eejit

! Last night we saw a mother fox with 3 cubs playing in the street. This is north London at 1:30 AM .

When I lived in North London, you'd see foxes often enough. There's must be hundreds of them between Wembley going straight down to Ealing.

But what really got me about North London were the ants. They're everywhere during the summer.

In Dublin, the widllife seems to be limited to seagulls and crows :)


Sean McGrath, CTO, Propylon

It occurs to me that hyperlinking can be used as a way of writing stuff between the lines as it were. A sort of visible subtext if you like. Hmmmm. Does this idea have a name. Suggestions?

Subliminal linking, aka sublinking :-)

July 21, 2003

Eckel on Programmers

Bruce Eckel's MindView, Inc: 7-20-03 The Ideal Programmer

But I don't think this is a person who is part of our profession, but rather someone who just exists in our profession. And probably because, long ago, someone said "get into programming, it pays well."

Trang task for Ant

You can find it here. It's a beta, but if you give it a whirl, feedback is welcome.

July 05, 2003

Echo assumptions

Sam Ruby: necho 0.1

Add namespaces to those assumptions.

July 01, 2003

The Echo wiki

Social Software

Most wikis that matter don't operate on a public scale, being used for coordination of small and focussed groups. (IAwiki.net is about the largest I've seen.)

I count 663 pages on IAWiki. C2 wiki has pushing 25,000 - it's the foremost public repository of programming wisdom on the planet. Clay doesn't mention C2 here, even though it's creator, Ward Cunningham invented Wiki nearly 9 years ago. C2 definitely matters.

It's fascinating to watch people adapt from the highly personal medium of blogging to the interpersonal medium of wiki.

My observation on the Echo Wiki. It doesn't have WikiNature. For example if you want people to alter your text over there, you're encouraged to add RefactorOK to it. That's not good - a Wiki works by continuous editing and refinement - there's no real notion of ownership or releasing of 'rights'. A wiki will degenerate unless to community takes it on itself to refactor and keep the place tidy. This is painful sometimes - I've had stuff deleted from C2 and didn't like it, but the overall effect is that a refactored wiki always has the best content possible. Even now the pages on Echo wiki are getting messy and the site will start to rot unless they're cleaned up. It's hard to do this if the norm is DontTouchMyStuff. And arguably, DontTouchMyStuff is the main reason Echo exists. The tone is brash too - it's a little 'warm' over there, but the ad-hominem nonsense you see on weblogs hasn't arose.