[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] [prov] Re: Finding a local artifact repository containing a required artifact


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 a
> url/uri world they are relative paths)
cool


> - 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)
sure


> - is the FORMAT property a convenience for distinguishing between
> 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 (with processing),
> 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

> Jeff McAffer wrote:
>
> the descriptors capture information that the repo uses to
> get/process the artifact.  For example, the steps.  Folks who are
> 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 more
> or less of the data in a descriptor.  When looking to see if a repo
> 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.