Wednesday, 2 April 2008
It’s become quite fashionable for large IT shops to give blanket Royalty-Free licenses for implementation of “core” technologies, such as XML, Web Services and Atom. I’ll refrain from linking to any of them, as the purpose of this post* is not to pick on any single one**.
Rather, it’s to call attention to a blind spot. IT folk see these licenses, nod their heads and relief, and assume that all is well; they can use this technology in their projects without fear of at least a handful of big, bad companies coming to get them.
That’s not the case.
You see, most of these licenses are restricted to the implementation of this technology, not its use. This clears the people who actually write the code that implements the [ XML, Web Services, Atom ] parsers, processors and tools, but it doesn’t help the folks that use those things.
I should point out that this isn’t limited to these one-off “commitments”; the vaunted W3C Patent Policy says:
“Essential Claims” shall mean all claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by implementation of the Recommendation.
In other words, people who implement XML parsers are free from worrying about any W3C Member for coming after them, while the people who use those parsers are out in the cold; if you’re using XML for healthcare, the same folks who make those commitments can have “XML in healthcare” patents and come after you.
In effect, the vendors are pooling together their IP and giving each other free cross-licenses on chosen technologies — calling a truce, if you like — but not including their users. A rapacious vendor could hoard IP relating to the use of a technology, push it as a standard to get wide adoption, and then cherry-pick cashed-up users to get the most revenue from patent enforcement.
Is it on purpose? In most cases I doubt it, but that’s the outcome, and it’s important for people to understand it. Can we do much about it? Probably not, unless somebody gets really generous and starts a patent pool. Sorry to end on a down note, but patents are involved, after all…
* Since it’s a sensitive subject, I should point out that I’m not wearing any of my various hats when writing this post; it just reflects my personal thoughts, and I am not a lawyer, or *shudder* a patent lawyer, so take it with a huge grain of salt.
** No, the timing is not purposeful; recent events merely reminded me that I wanted to post this.
Thursday, 20 March 2008
Having complained before about the sad state of HTTP APIs, I’m somewhat happy to say that people seem to be getting it, producing more capable server-side and client-side tools for exposing the full range of the protocol; some frameworks are even starting to align object models with resource models, where HTTP methods map to method calls on things with identity. Good stuff.
However, something’s been bugging me for a long time about this. While there’s a nice internal logic to mapping HTTP methods to object methods, it doesn’t realise the power of having generic semantics.
Consider a resource;
class Person (Resource):
def GET(self):
# do acls...
# get the representation out of some persistent store
# translate to the format asked for
return representation
def PUT(self, representation):
# do acls...
# translate the representation to the appropriate format
# put the representation into some persistent store
# cook up a status message
return status_representation
def DELETE(self):
# do acls...
# delete the resource from some persistent store
# cook up a status message
return status_representation
def POST(self, representation):
return representation
In this interface, GET, PUT and DELETE all have well-defined semantics. So well-defined that they really shouldn’t need application-specific code; after all, they’re just manipulating state in well-known ways.
In fact, I’d posit that you can specify the behaviour of any RESTful resource by describing a) the processing that POST does, and b) any side effects of PUT and DELETE.
There are a lots of caveats around that, of course. You need to define access control for the methods, and specify if authentication is required. You need to specify the formats that the application can work with (potentially with differing answers for input and output, and possibly with appropriate translations). You’ll need to specify the processing that happens around query parameters (e.g., in filtering output for GET).
The thing is, none of those have an implementation that’s specific to this particular resource; instead, they’re better abstracted out, so that the implementation looks something like this;
@store_type("mysql") # tell the Resource what implements GET, PUT and DELETE
@acl("choose your ACL poision") # tell who / when access is allowed, per-method and finer-grained
class Person (Resource):
store_format = PersonML
def POST(self, representation):
# operate on the store...
return representation
def PUT_effect(self, representation):
# called IFF the presented representation is storable,
# but before it is available; raising an exception will back it out
return status_representation
class PersonML(Format):
translations = {
'application/xml': (self.to_xml, self.from_xml),
'application/json': (self.to_json, self.from_json),
}
def to_xml(self, native_input):
# do whatever you've got to do
return xml_output
def from_xml(self, xml_input):
# do whatever you've got to do
return native_output
...
I haven’t incorporated a way to handle query parameters here, but you get the idea.
The tantalising part of this approach is that it can be implemented close to your persistence layer; all you need is hooks in the right places for side effects and POST processing. In fact, as long as you’re willing to be flexible on consistency, you can almost do it with mod_rewrite (calling a completely separate script as well as PUTting/DELETEing the state doesn't yet seem to be possible; ping me if you can figure out how to), and stuff like Apple's FSEvent looks very, very interesting in this light.
Is anybody aware of anything along these lines out there in an existing tool or framework? I’ve been meaning to write some code along these lines for some time; if you'd like to help out, please drop me a line.
The other place that this view has impact is in describing RESTful applications, if you believe in doing such things. WADL, for example, gives GET PUT and DELETE equal weight with POST, when I’ve always suspected it would be more elegant if you took the abstraction up a notch and talked about state, rather than methods.
Monday, 3 March 2008
Not many people that I know outside of IETF circles realise that a new *DAV effort has started up; CardDAV.
An address book access protocol leveraging the vCard data format.
The Internet-draft draft-daboo-carddav will be the starting point.
The WG is explicitly cautioned to keep the base specification feature
set small with an adequate extension mechanism, as failure to do so
was a problem for previous PAB efforts (ACAP).
Draft-daboo looks like it’s taken a page out of CalDAV — another recent *DAV effort that is gaining traction.
All of this led me to mutter “DAV WTF?” at the IETF APPS Architecture Workshop the other week. Do we really need to give folks the opportunity to mint more application-specific methods and headers?
Interestingly, Lisa Dusseault — one of the core folks in the DAV world — blogged about this the other day;
Were I to propose CalDAV today it would probably be CalAtom — some things would be easier, some harder, but it would catch a wave instead of drifting in the tail of something that was never much of a popular wave. Oh well, we needed something then, and WebDAV gave the most leverage at the time.
I gave a big sigh of relief when I read that, and I hope that the CardDAV folks take this to heart. Some parts of WebDAV (e.g., properties; see Yaron and Larry on this) deserve to be taken out back and shot — although, as Lisa says, they were necessary because of the state of the art at the time. That doesn’t mean we can’t do better now.
Sunday, 17 February 2008
It’s 7am, I’m sitting in the Auckland Koru Club on my way home and reading the minor kerfuffle regarding PATCH with interest.
For me, the critical difference between PATCH and POST is generality; PATCH is a generic method (as all good HTTP methods should be), while POST is not (the exception that proves the rule). As such, it should be possible to take a PATCH request and a current representation of the resource it’s being applied to and — only armed with knowledge of the format that the PATCH request has chosen to use — accurately determine what its new state is.
James says
[..] using POST is still problematic, mainly because it ties the client to whatever meaning any particular server implementation wishes to assign to POST in any given context. E.g. POSTing one of Rob’s “x-application/json-sync” resources to the Edit URI of an Atompub entry has a different meaning that POSTing the same resource to the URI of an Atompub collection URI. Using PATCH would avoid the ambiguity entirely and ensure that the same request would have the same meaning regardless of the URI.
which I totally agree with — provided that the request really is unambiguous, and doesn’t have a lot of resource-specific semantics that aren’t captured in those of PATCH.
For example, the common case that I see is what Joe originally spelled out; a special resource is minted that has the semantics of updating other resources (e.g., for batching). While you can fit this sort of thing into a world view where you’re PATCHing a special-purpose resource that has side effects on other resources, I think it’s a looong stretch to say that this is just a PATCH; POST would make it more clear that something special is going on here and require that the protocol be really spelled out somewhere.
In short, while PUT and PATCH can have side effects, if the whole point of the resource is to propagate those side effects, you might be stretching the semantics of these methods too far, and providing a false sense of security (what’s called “standards air cover” by the cynical), by extending their semantics in non-standard ways and relying on clients understanding what you’re doing under the covers.
Likewise for PATCHes that contain obscure or special-purpose patch document formats. If you’re creating application/x-my-apps-patch-format, you’re not doing anybody any favours by using PATCH, which needs to be paired with a standard patch format to be of any real use.
This is why I found Rob’s post so interesting; a lot of my concern in using PATCH has been that creating patch documents is a difficult thing to do on the client side (e.g., with JavaScript). The existence of sync.js makes this a lot easier — provided that your data model is JSON. Anybody got one for XML?
Wednesday, 13 February 2008
I’m back in the Bay Area for work, and out of curiosity I thought I’d check in on the housing market here. After updating my super-secret source of housing sales, I tried something new; charting price paid for square foot by county.
This was on a tip from Mark Mansour, a fellow recent Melbourne homebuyer; although it’s not perfect, valuing just by land size is a simple, frank and easy-to-calculate assessment of price.
Here are the results; I filtered out homes whose habitable square footage was near the land size, to try to remove apartments.
The interesting things to note;
- San Francisco is expensive, and strong;
- The Peninsula and Marin have flattened out, but aren’t dropping (at least in nominal value)
- The East Bay, Napa and Sonoma are starting to dip, in nominal and real terms.