Stefan Liebig <Stefan.Liebig@xxxxxxxxxxxx> wrote
on 10/24/2007 09:33:55 AM:
> I am trying to reflect on this topic. It is a little bit messed up.
> It is more like writing on a white board. Sometimes that helps.
> - artifact keys are unique identifiers for artifacts (analogy: in
> url/uri world they are relative paths)
> - artifact descriptors are unique identifiers
for ´bytes´ that can
> be turned (processing steps) into canonical artifacts (analogy:
> uri/url they are absolute, i.e repo url + relative path from the
> key, the query part are the steps)
> - is the FORMAT property a convenience for distinguishing
> different types of processing steps, e.g. transforming steps,
> validating steps?
the formwat was my attempt at abstracting the optimizations/steps. In
essence it is an opaque token that descriptor producers can use to tag
the descirptors they produce with information they can use to easily identify
things they have done. So for example the pack optimizer sets the
format to "packed". A delta optimizer might say "delta
relative to 1.1" or some such. For now this is doubling as well
as a string we can show users in the repo browsers so they can tell the
difference between the descriptors. That is a bit bogus but for now
it is ok.
> - maybe the artifact descriptor should not have
an equals() method,
> instead we should use different Comparators (some are predefined for
> the most common needs)
Yes, this feels like a good direction.
> - operations on artifact descriptors: mirroring
> replicating (no processing), creating, optimizing (i.e a form of creating) Right. Somehow this needs to be captured both
in the notion of equality/equivalence as well as in cloning.
> - an artifact descriptor containing steps can be a canonical
> artifact (with steps that are only validating)
Yes, that too needs to be taken into account.
Summary: What you are seeing is very early days
in this area. Please feel free to improve and add to the robustness
and completeness of the story.
> Jeff McAffer wrote: >
> the descriptors capture information that the repo uses to
> get/process the artifact. For example, the steps. Folks
> using IArtifactDescriptor do not need or get this information. The
> repo hands our a descriptor and can process it when the caller gives
> it back. In general one repo cannot do something with a descriptor
> from another.
> The problem is that we need sometimes to do things like equals() on
> descriptors. Dependingon the situation we may want to compare
> or less of the data in a descriptor. When looking to see if
> contains() a descriptor we may want to know if that exact descriptor
> is there (e.g., if I am doing some optimization I want to see if the
> optimized descriptor is already in the repo) In other cases you have
> a descriptor for something that is being mirrored/created/optimized
> and you might not know the size yet but do want to know if the repo
> has the same thing (i.e., so you want to compare on a more limited
> set of properties).
> It would be great to get away from these differences but currently
> I'm not seeing a way.