OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sdd] Alternate definition of artifact


Hi -

I agree with James that the definition of the word artifact does refer
to "product of human conception or agency rather than an inherent
element" and therefore excludes the payload.  

So we end up with one term missing, which is the aggregation of the
artifacts and the payload:

What do we call : zero or more files representing everything necessary
to perform a  lifecycle operation on a resource?

Regards,
Debra

-----Original Message-----
From: James Falkner [mailto:james.falkner@sun.com] 
Sent: Thursday, April 20, 2006 10:59 AM
To: sdd@lists.oasis-open.org
Subject: Re: [sdd] Alternate definition of artifact

I am in agreement with Julia.  We need a definition of payload if we are
going to use it in the context of another definition.

In my opinion, end users who are deploying solutions don't care how it
works -- they care that the appropriate bits are put in place and the
appropriate services are started.  I consider the "appropriate bits" as
the payload.  Everything else (the SDD, the RPM metadata, etc) is just
ancillary to the ultimate goal of getting the bits laid down and
services started.

In other words, when I hear "payload" I think of that as the
"appropriate bits" that the end user is interested in deploying, not the
support metadata and "helper applications" that help (aid) in getting
the payload in place.  payload == the load that pays.

When I hear "artifact" I think of all the ancillary, helper bits that
aid in getting the payload deployed, but aren't of interest to the end
user doing the deployment, and don't typically live on to see the light
of day after deployment operation is complete.

So, I am uncomfortable with including "payload" as part of the artifact
definition.  I think of artifact as anything that is not the "payload".
Artifacts are short-lived, helper stuff (SDD XML, deployer tools, XSLTs
used at deploy time, etc) used to get the bits in place (or "perform a
lifecycle operation on a resource").

-jhf-

Christine Draper wrote:
> How about:
> 
> *Artifact:* zero or more files representing the payload (e.g. binary 
> content, instructions, definitions, scripts) necessary to perform a 
> lifecycle operation on a resource.
> 
> Regards,
> Christine
> 
> 
> Senior Technical Staff Member
> IBM, 11501 Burnet Road, Mail Point 901-6B10 Austin, TX 78758
> 1-512-838-3482 tl 678-3482
> Inactive hide details for Julia McCarthy/Raleigh/IBM@IBMUSJulia 
> McCarthy/Raleigh/IBM@IBMUS
> 
> 
>                         *Julia McCarthy/Raleigh/IBM@IBMUS*
> 
>                         04/19/2006 06:44 PM
> 
> 	
> 
> To
> 	
> 
> cc
> 	
> sdd@lists.oasis-open.org
> 
> Subject
> 	
> Re: [sdd] Alternate definition of artifact
> 
> 	
> 
> 
> This proposal depends on the definition of payload. You seem to be 
> defining it as only the solution content that is so closely similar to

> the resulting solution resources that people think of it as the same
thing.
> 
> Note that even when the package content is closely similar to the 
> deployed resource, it is never the same thing. A file in a package is 
> not the same thing as a file created in a filesystem. To my thinking, 
> all of the content of a solution package is instructions for creating 
> the solution. The instructions might happen to be a list of the exact 
> bits that will be created on the file system - for example, a readme 
> file that gets created in a particular location by copying the set of 
> bits included in the solution package. I don't yet see any value in 
> distinguishing between instructions that are closely similar to the 
> resulting resource and instructions that are clearly different from 
> the resulting resource. And since I don't see value in that 
> distinction, I am not inclined to define payload as only the solution 
> content that is closely similar to the resulting solution resources. 
> Which means I am not inclined to agree with your proposal.
> 
> Julia McCarthy
> Tivoli Development
> Deployment Engine Design
> julia@us.ibm.com
> 349/8156
> 877-261-0391
> 
> 
> 
> Inactive hide details for "Josh Allen" <jallen@macrovision.com>"Josh 
> Allen" <jallen@macrovision.com>
> 
>                                                 *"Josh Allen"
>                                                 
> <jallen@macrovision.com>*
> 
>                                                 04/19/2006 07:23 PM
> 
> 	
> To
> 	
> <sdd@lists.oasis-open.org>
> cc
> 	
> Subject
> 	
> [sdd] Alternate definition of artifact
> 
> 	
> 
> 
> Hi all,
> 
> On the call today I suggested an alternative definition of the term
> *artifact* that might help us feel more comfortable with this term. At

> request I've included it here for review:
> *
> Artifact:* zero or more files representing a payload and if necessary 
> a set of instructions about how to use that payload to perform a 
> lifecycle operation on a resource.
> 
> Thanks,
> Josh
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]