Re: [buckminster-dev] Re: Transient resolve and generated versiontypes

["ken1" <kenneth@xxxxxxxxx>]

(resend as I accidentally sent it only to Thomas...)

I'm feeling that it's upside down to set table etc on a provider - I
still feel that it is a particular component that is associated with a
particular version type. Again, this is assuming the version type is
constant across all the places and in all forms that component can be
found (I can't see that happening, but if it would, all these
arguments go out the window of course).

So, in a cspec when you express a dependency you fundamentally express
a query. Information about how the query should be resolved should not
be part of the query. Somewhat reminiscent of that in an SQL query you
don't really trouble yourself much with the exact datatypes of the
fields you query for, that's the db engines problem.

Consider that I have ten completely separate components in separate
project. However, they all need a common component A (in various
versions). Why should all ten detail how the version designator should
be interpreted? That's just redundant. Just letting the component name
be a key to a single instance of this type of information seems more
correct and efficient to me... It's just a form of normalizing, no?

You claim that the editor may/will need the version type information.
This is a valid point. In principle, it's arguably possible for the
editor to do the same lookup in the rmap (or elsewhere, see below) and
thus get the version type information it needs. Ok, maybe there are
instances when you work with a cspec and don't yet have the
rmap...fair enough, that would be a problem. Solve by 1) make sure
there's an rmap first, or 2) ask the user to manually provide such
information, or 3) simply keep the version type info as is in the
cspec, but come resolvement time, that information *must* be equal to
what the rmap says (this would be sort of a compromise between having
it in one or the other place).

Maybe the existing split is not rich enough...what about splitting the
rmap into more than one thing - perhaps a 'cmap', a component
map/database. Now, the query expresses 'what I want', the cmap
expresses 'what it is', the hard facts about the component (the
component name is the key), and the rmap expresses 'how to get it'.

ken1