[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sdd] Alternate definition of artifact
Hi there, I agree with the below part of the James's comment. James Falkner wrote: > > 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- Here is my opinion regarding to this: If a file is not parsed or interpreted in the deployment process, it will be probably used by software itself in runtime. SDD should consistently handle it as an opaque object in its context. These may be called payload for the deployment package. If a file is parsed or interpreted in the deployment process, it needs to be specified in SDD specification. The data in the file may be called metadata since the software won't needs them runtime. While some metadata can describe property (for example, file names, size, digest value ) of payload files, the metadata should be kept in separate files from the payload. (payload is not modified.) I think the critical need for distinction is whether it is parsed or interpreted in the deployment process. If it is true, what we need to define the term are the above two concepts. I'm fine with "payload files", but not sure about files containing metadata. To tell the truth, it's not very clear to me why the word artifact is used everywhere in our discussion. (this may be language problem of me:-) In my reference, the artifact is described as: tool; object; man made object (often referring to primitive tools) I think that's true for everything we are discussing. We are not discussing about natural material. -Keisuke P.S. I'm sorry if I missed the point. A non-native speaker comment:-)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]