Re: [widgets] Authorities will never have authority?

Hi Jonathan,

On Dec 23, 2009, at 21:10 , Jonathan Rees wrote:
> My compromise solution would be to specify something that current
> widget: URI minters (producers) can write that is assured to connote
> NOTHING to all future widget: URI consumers, for example the empty
> string. That would futureproof the field without forbidding it. It has
> pretty much the same effect as what Larry proposed (optional
> authority). You could for example say that the empty string has this
> property.

I don't think that that would work. If you look at the example I give of a naïve processor written from the consumers' side, one can expect the exact same issue to surface with a constant string being defined as you propose (just vary the length parameter in the call to substring).

> The problem with the current spec is that no such value is
> provided, so all producers will live in fear (given the way it's
> currently worded) that something they say now will have unintended
> meaning in the future.

I hear your concern, but I think that we have a trade-off to make between two unpleasant options, and I feel much safer with the one that the current specification makes.

A produced widget URI only lasts as long as a given UA is running; its pattern only lasts as long as a given UA version is deployed. These aren't necessarily short time frames, but they're shorter than the lifetime of content (which appears to be essentially infinite in some cases).

Given a choice between an approach that risks leading to broken content that would prevent evolution (a fixed authority, no authority, the empty-string authority) and one that risks having v2 content that would make poor interpretations while running on a v1 implementation (optional opaque authority), I think that the latter is less risky and more future-proof.

It's not a sexy trade-off to have to make for sure. I think that what we're seeing here is fodder for the TAG's discussion on web applications and API: widgets are offlined and somewhat insulated web application units; they had to use URIs because URIs are exposed left, right, and centre in web technology; coming up with a URI scheme that works in such an application context leads to it having properties not normally expected (or considered desirable) in a regular URI scheme, but that may make sense in this situation.

In other words it's not impossible that this is just surfacing impedance mismatches between web arch as we've been used to handle it, and how it pans out when some application architectures are built around web technology. Solutions on a postcard! ;-)

-- 
Robin Berjon - http://berjon.com/

Received on Monday, 11 January 2010 16:40:50 UTC