RE: Splitting off core: where we stand

> Subversion: bunch o' options
> Oracle: requires workspaces and baselines
> Rational: nothing stated publicly :-), but they're doing a
> bunch of options
> Xythos: core
>
> So... there is certainly support for saying that core by
> itself is pretty useless and not the focus of most
> implementors. And if that is the case, then why bother to
> break it out (with the hope that it gets standardized
> sooner rather than later).

Greg, I think your data supports my point.  Xythos is the only WebDAV
server that is not doing source code control, that is planning to
implement any part of DeltaV.  I think I'm the only person designing a
versioning server that isn't for source control, that has bothered to
read the entire spec, but then I'm used to daunting technical documents.

Let's take a step back. Originally we had a single document without any
distinction between core and options. In response to complaints that it
was too complicated, and massive overkill for simple scenarios, we
labelled some of the material core and the rest options. Now, there are
essentially four situations:

(1) Core useful, options useless.
(2) Core useful alone, options useful.
(3) Core useless, core + options useful.
(4) All of DeltaV useless.

In case (1) our best move is to simply throw away the options and
publish core.
In case (2) we should be able to publish core but since there's
significant demand for the options they ought to be standardized
relatively quickly.
In case (3) we should throw away the distinction between core and
options and publish one monolithic document.
In case (4) we should all go home.

Keeping core separate but in the same document is a half-measure that in
my view serves no real purpose. I'm particularly unimpressed by the
argument that standardizing core alone will hold up standardization of
the options. If the options aren't interesting enough to stand on their
own then we should throw them away, not glue them to core so that the
IESG has to take all-or-nothing. We're trying to design a broadly
implementable technical standard, not pork-barrelling in Congress.

Lisa

Received on Thursday, 8 February 2001 13:12:08 UTC