Re: [sdd] Alternate definition of artifact

[Julia McCarthy <julia@us.ibm.com>]

Sounds like we (James and I, at least) have reached agreement. I can see that there could be operational benefit in knowing which files will not need to be parsed during deployment, so I'm now happy with including definitions of both payload and artifact. I'll copy those "final" definitions here so others don't have to dig through the email thread.

Payload:

Binary packaged content intended to be delivered, without change, through a solution
deployment.

Artifact:

Zero or more files or metadata used to perform a lifecycle operation on a resource.


Julia McCarthy
Tivoli Development
Deployment Engine Design
julia@us.ibm.com
349/8156
877-261-0391



James Falkner <james.falkner@sun.com>

James Falkner <james.falkner@sun.com>

04/25/2006 05:55 PM

To	Julia McCarthy/Raleigh/IBM@IBMUS
cc	sdd@lists.oasis-open.org
Subject	Re: [sdd] Alternate definition of artifact

Julia McCarthy wrote:
> I think payload files are part of artifacts. (Using your definition of
> payload.) Artifacts can be payload files or metadata or metadata plus
> payload files. An artifact is everything that needs to be given to the
> hosting environment in order to perform a lifecycle operation on a
> resource.
>

Sure, I agree.  I was thinking about the case where the deployment is done
all on the same host, so in that case no artifacts are transmitted over the
wire.  But I don't see value in that distinction, so I agree that payload
files are always, at some point in their lifetime, part of an artifact,
sometimes for a short period of time and sometimes longer.

> How about these modifications to your proposed definitions:
>
> Payload:
>
> Binary packaged content intended to be delivered, /without change/,
> through a solution
> deployment.
>

I like that one.

> I still don't see the value of distinguishing between content that is
> delivered without change and content that is changed or used to compute
> delivered content. Can you give me an example of the value provided by
> distinguishing between what you call payload content and the other
> content of the solution package - such as the .ini file that will be
> modified or the DDL script?
>

The value is that if the content that is delivered without change can
be separated (within the solution package) from the content that is used
during development, then an install runtime can ignore (i.e. not access
and not have to interpret file structures, directory names, weird formats,
etc) the unhanging payload, and can transmit it in stream format, or in
some other more efficient method, because it never has to parse it
or try and understand it.

Presumably this means that artifacts (those that are truly used in support
of deployment of the payload) would be somehow separate in the solution
package, in a well-defined spot where artifacts go, so that installer runtimes
don't have to dig around filesystem layout tar files (which could even be
different per platform).

> Artifact:
>
> Zero or more temporary files or metadata used to perform a lifecycle
> operation on a resource, but not specifically tied to the objective of
> the operation.
>
> Temporary would be ok with me in this definition, except it seems to be
> used here to indicate these are not payload files. I believe that all
> payload files would be part of some artifact or other, since being part
> of an artifact is the only way they become available to a hosting
> environment to perform a lifecycle operation.
>

Yes, I agree that all payload files would be part of some artifact at
some point during the deployment.  But once files are deployed they are
no longer part of an artifact.  They simply exist on their own in their
final deployed state and location.  And then any artifacts are cleaned up,
as they are no longer needed.

> I actually think we could do without two concepts. We just need the
> concept of "everything provided by the solution package to the hosting
> environment to allow a lifecycle operation to be performed". That's what
> I call an artifact. I don't care whether those things are copied
> exactly, modified slightly or instructions that are completely thrown
> away. What I care about is what the hosting environment needs to perform
> the operation.


Well, with that I wholeheartedly agree and I would be fine with that as a
definition of artifact.

In that case, the value of defining payload is in allowing payload to be
handled more efficiently by runtimes, if they know that it is never to
be changed or parsed.

-jhf-