[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]