Re: Another take on versioning

On 12 Oct 2009, at 22:33, Henry S. Thompson wrote:
>> The most troubling part of this approach is the way in which  
>> "invalid"
>> has to percolate through the pipeline and be taken into consideration
>> in different places:
>
> So, how can we avoid percolating at all. . .

I don't think you can, even if you *do* know the signatures of the v2  
steps, you don't know how to process them. And you really don't *need*  
to know how to connect them if you're never going to run the sub- 
pipeline that they're contained in: working all that out is just extra  
work.

> I'm left feeling that getting rid of requiring the declarations is
> what's causing all this trouble.  Let's weigh up two alternative bad
> scenarios:
>
> Scenario 1, with today's design: Jeni points out that having one
> pipeline import the V1 declarations and a library, which in turn
> imports the v2 declarations, will cause a static error (conflicting
> definitions).  Actually of course _that_ won't ever happen, because
> no-one will ever explicitly import the v1 library -- they don't need
> to.
>
> So Scenario 1 will only arise when we publish v3 . . .

Unless someone actually does use a <p:import> within their v1  
pipeline, which they are actually allowed to do, aren't they? And  
given that's their only way of indicating the version of XProc  
required for their pipeline, they're well within their rights to do so.

Let's imagine the situation a couple of years down the road. There are  
several v1 processors around, and a set of pipeline libraries built by  
the community or individuals that are in common use. Then v2 comes  
along, only one processor actually implements it, and the pipeline  
libraries are updated to add a few juicy new pipelines and to take  
advantage of v2 processing where they can, but fallback to the old v1  
processing.

(This example scenario is extremely similar to the situation with XSLT  
2.0.)

Now what happens? Of course developers update the pipeline libraries  
that their pipelines use, especially because they want some new  
pipelines that have been added, but not everyone updates their  
pipeline processor, mostly because they can't (because they're built  
in to the databases that they've paid vast sums of money for).

Now:

   (a) whenever those people run their pipelines, the processor has to  
make a connection to the W3C server to get hold of the v2  
declarations. On some websites, this is every time there's a request  
to the website. The people using the pipelines are largely oblivious  
to this fact, with the result that there are millions of hits per day  
on the W3C website requesting that pipeline library, amounting to a  
DDoS attack. One day, the W3C website is unreachable, effectively  
preventing thousands of other websites from working.

   (b) developers on planes get extremely pissed off at not being able  
to run their pipelines at all just because they lack internet  
connectivity.

Fortunately, the developers of the shared libraries forsee these  
issues, so they actually publish two sets of pipelines: one for v1 and  
one for v2. Developers of websites forsee that access to the XProc v2  
pipeline declarations is going to be a problem, so they put in place  
proxies and catalogs and so on to get around it.

In this scenario, the users of XProc can't actually use forwards- 
compatible mode, because to do so would be to rely on something that  
fundamentally can't be relied upon -- network connectivity.

I think the cost of this is extremely high, not to the few XProc  
implementers, but to the large (we hope) numbers of XProc users.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Tuesday, 13 October 2009 08:46:38 UTC