Apple shows Microsoft how to really do an “I’m a PC, I’m a Mac” advert:
http://movies.apple.com/media/us/mac/getamac/2009/apple-mvp-elimination-us-20090512_480x272.mov
Awesome.
Category “miscellaneous”
More forums, and a French translation
I’ve finally added a new forum for Snake Wrangling for Kids (python programming book for kids), and another for stomp.py.
Neither pages were attracting a huge amount of comment traffic, but even the small number of comments was becoming unmanageable.
On the SWFK front, it looks like the French translation is approaching completion — the current draft looks brilliant (arguably better than the original). Michel has done an excellent job. This is the first translation, and I’m keen to see more…
Units of Work
In regard to cross-resource transactions, I’m a member of the camp that wonders whether distributed transactions are strictly necessary in the REST/HTTP world; indeed I wonder whether they represent a design failure in modeling the granularity of your resources.
That said, we don’t live in a perfect world — and even if I can’t envisage why a properly designed RESTful application might require access to a distributed transaction, I can certainly envisage the environment where such an application might evolve. I’ve worked in a few of them. Places where interdepartmental barriers are as solid as the Great Wall; bastions of archaic technology where “one might provide a pseudo-RESTful interface, but one certainly won’t be re-architecting one’s legacy system in the buzzword language of the day”.
But, I think there’s a certain amount of smoke and mirrors in the JBossTS article “Transactional support for JAX RS based applications“:
Certainly it is worth pointing out that if a system cannot be made reliable then it can be of only limited utility. That said it is a worthwhile exercise to show how a REST based system can be made reliable.
Lack of distributed transactions would hardly seem to make a REST based system “unreliable” and, as a consequence, of “only limited utility”. Imagine a hotel booking facility — perhaps a booking resource, which internally might be constructed from a number of components, all governed (again internally) by transaction demarcation. Does the fact that the booking resource is coarse-grained and does not require an external transaction make it less reliable than a number of fine-grained resources which do? On the contrary. The latter sounds more like a WS-* api than a RESTful architecture, nothing to do with reliability.
So… hopefully it’s obvious I think it’s a bad idea. But if I were to write such an API, I think the 8-year old spec mentioned in the article falls short of the mark. Here’s my first-cut attempt at an alternative (which I still think falls a bit short of the mark, but is possibly an improvement):
| Resource: tc | ||||
|---|---|---|---|---|
| Method | URL | Content | Description | Statuses |
| GET | /tc | Returns HTML containing a summary of all transactions (status), plus an href to the transaction detail | 200 – ok | |
| /tc/{txid} | Returns HTML containing detail for the transaction with id {txid}, including the status and a list of hrefs to the each of the participants. For example:
|
200 – ok 404 – if txid is not found 409 – if the transaction has been deleted |
||
| /tc?status={status-type} | Return HTML containing a summary of transactions with a specific status, with href to the transaction detail For example: /tc?status=recovering or /tc?status=active |
200 – ok | ||
| /tc/{txid}/participants | Return a list of participants in the transaction (list of hrefs) | 200 – ok 404 – if the transaction does not exist |
||
| /tc/{txid}/partipants/{rec-coord-id} | Return HTML containing the detail of a participant. For example:
|
200 – ok 404 – if the transaction or participant does not exist |
||
| POST | /tc | [timeout={timeout}] | Start a transaction (with default timeout) returning the url /tc/{txid} — which is deleted after the timeout or after completion (any HTTP method relating to {txid} thereafter returns 404). Use timeout={timeout} to override the default timeout period. | 201 – created |
| DELETE | /tc/{txid} | Rollback and stop a transaction | 204 – ok 404 – if the transaction does not exist |
|
| /tc/{txid}?commit | Commit and stop a transaction | 204 – ok 404 – if the transaction does not exist |
||
| POST | /tc/{txid}/participants | url={url}&[name={name}] | Enlist {url} in the transaction, returning a unique resource for that participant of the form /tc/{txid}/participants/{rec-coord-id}. If name exists, record against the participant detail | 201 – created 404 – if the transaction does not exist |
| PUT | /tc/{txid}/participants/{rec-coord-id} | url={url} | Replace the participant url | 200 – ok 404 – if the transaction or participant does not exist |
The resource identified by a participant URL will have the following semantics:
| Method | URL | Content | Description | Statuses |
|---|---|---|---|---|
| PUT | URL/tx/{rec-coord-id} | action=prepare | The participant prepares any work done in the context of the transaction. The Warning header will contain additional info about the state of the prepare (either readonly, or notok). | 200 – ok 200 – ok (+ Warning: readonly) 200 – ok (+ Warning: notok) 404 – participant has rolled back |
| action=commit | The participant commits any work done in the context of the transaction. | 200 – ok 200 – ok (+ Warning: heuristic) 404 – participant has rolled back |
||
| action=rollback | The participant commits any work done in the context of the transaction. | 200 – ok 200 – ok (+ Warning: heuristic) 404 – participant has already rolled back |
Basic usage might look something like the following:
| 1. Create a new transaction resource | |
|
|
| 2. Create a new resource of some kind (notify the resource that it will operate with a distributed transaction) | |
|
|
| 3. Update another resource (again notify that it will be operating within a transaction) | |
|
|
| 4. Enlist the url for each resource in the transaction | |
|
|
|
|
| 5. Commit the transaction | |
|
|
| 6. ‘Behind the scenes’, the commit results in the following (2-phase commit at this point)… | |
and |
|
Writability
Dumb.
I left .htaccess writable, and something (maybe wp-super-cache…?) corrupted it. Of course, this left my blog completely inaccessible — and not sure how long for.
Mental note… do NOT do that again.
We apologise for this temporary interruption in our services. We’ll be back with you… well now, actually.
New forums for YAK
I’ve finished migrating comments from the original YAK pages to the new forums. Slightly less painful than it could’ve been, after I wrote a quick app to automate much of the process — but it was still fairly labour intensive. Which is a long-winded way of saying, if comments have wound up in the wrong place (or gone missing), it’s probably due to the manual process.
There are 3 forums for General Discussion, Suggestions and Bugs. Hopefully they’re more navigable than the previous comment system.
New theme
I’ve (rather obviously) just updated my theme, and added a new forum. If anyone notices anything odd, please let me know.
I’ve also begun the rather laborious process of moving comments on the YAK general discussion page into the forum (unfortunately there’s no straightforward, automated method). I’ll probably lose interest in the process long before I reach any great percentage of the 500 comments on that page, but please note comments are now closed on those pages — anything new should go directly in the forum.
11K
A recent visit by Slashdotters (which I had no idea had happened until after the fact) finally tipped the download stats for SWFK over 10K. 11767 (at time of writing), to be exact.
I have no idea how that compares to ‘real’ books (i.e. stuff that is printed… or sold in fact), but it seems like a reasonably impressive number to me… at least, for an unmarketed, self-published effort.
Thanks for your support, and hopefully your kids are finding it useful. 
What is it with shoes lately?
First of all a journalist throwing his shoe at Dubyah, then shoe company throwing their weight at a small NZ online retailer:
British (shoe design [sic]) company, Jimmy Choo has told the north of Auckland gift seller website, Kookychoo.com, it must agree to give up its name by Tuesday, or face a lawsuit.
I have to admit, I find this kind of thing (the latter rather than the former), really annoying. Undoubtedly some kind of Freudian “David versus Goliath” kind of thing.
I have no problem with a company trying to protect its brand, but I have a big problem with the manner and terms by which they do so. In any case, let’s face it, the only reason one might associate the brand “Kookychoo” with “Jimmy Choo” is now because of this case.
Quote of the Day…
Quote of the Day goes to Roy Fielding for the excellent:
That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating
Word on the Mac is a Mess
Word on the Mac is a mess, and I don’t like Excel much either. The lack of VBA macro support means it’s useless for the purpose I originally bought it for — teach me to not double-check the specs before I buy.
Worse yet, Word appears to no longer support Thai language — meaning it’s not fit-for-purpose for my wife either. Unfortunately, we left the Office 2003 disk in storage, back in NZ, so we can’t rollback to the version of Office that did support Thai language.
Exactly why is Office such a cash cow for Microsoft? Because of muppets like me, obviously.
