RE: [acs-wg] An AA creation use case
Keisuke, I believe that the most prudent solution needs to take into account the following two principles: - the repository needs to be able to handle (within the limits of the hardware set) any amount of application contents and associated data for a system (one notional AA). - Something must maintain the notion of the version and integrity of system (via one notional AA), through proper referential integrity and signature. In response to your questions:
I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them).
I am not particularly hung up on names right now, that is a refinement issue, and not a defining structure. The issue is whether there should be a porttype which has a method for pushing an entire and complete physical AA into a repository. Here is my take on the issue: - In the case of an ACS implementation, sending an entire AA imposes a need to "know" about a physical file format. This is contradictory to our statement that "we will not define how an ACS will store it's data". For example, if my implementation of ACS requires a method in the porttype that requires the acceptance of a physical AA file, then I must parse the AA file into parts in order to store it into the format that my implementation has chosen. Perhaps my AA file is stored in thousands of DB2 or Oracle records, since using one record to store an AA file will most likely fail at some point when too big. If I had porttypes that allowed me to remotely construct an AA, we can punt on a physical format and an entire physical AA transmission format. Providing we have the appropriate porttypes to remotely construct, inspect, and retrieve parts of an AA, then we only need to define on the wire how to move parts of an AA around, yet we can still maintain the notion of an AA and it's integrity, since the interface that constructed it can enforce it's integrity. This is why Tom has outlined sending the entire AAD (hope that the correct acronym) when replicating. The receiver of the replica can inspect and traverse the AAD to find the parts to pull the file over in chunks... especially if there was "modified date" time stamp info on each individual part, then we could explore the replication model I outlined.
- A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far.
- I think this is what Tom has been trying to focus on in his .ppt last meeting. I seemed to have put my physical file comments in the previous question, sorry.
- Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.)
- it is related since defining how parts of an AA are created, accessed, modified, and removed have implications that, in the case of physical file formats, would need to be known by ACS if an ACS impl. decided to just write the received AA file to disk, and then later have to modify it.
- Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.)
I am not sure I understand this question. No matter what porttype spec we come up with, as long as we do not create any issues for the IDE's or ant (or any other client type), we should be ok. I think that having the client create one file will have scalability issues to remote clients of ACS for large AAs.
- Or anything else?
That's my take. Pete -----Original Message----- From: owner-acs-wg@ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Keisuke Fukui Sent: Thursday, July 21, 2005 4:48 AM To: Thomas Studwell; acs-wg@ggf.org Subject: Re: [acs-wg] An AA creation use case Folks, Today we gone through a good amount of discussion in the call on this. I'm comfortable with trying to find a better placement of the things in this way. I also appreciate Pete's time check today:-) I think it's valuable for us to brainstorm this so that we can have a logically correct, feasible and adoptable specification for our purpose. Having said that, I'd like to clarify the real point of the discussion: At first I thought it is a matter of whether register() or create(), then it turned out that it is the use case where the archive is created. Now it again becomes ambiguous to me what is the real matter behind the two different definitions for AA (or AA file). I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them). - A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far. - Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.) - Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.) - Or anything else? FYI, when I say we will standardize transport format of AA, it is to me means to define: - An XML schema of the Archive Descriptor (AD). - At least one physical format of the archive that contains everything needed either in real entity or in external reference. - Required piece of information (or file), optional one and extension mechanisms in an archive besides the AD. Is it a wrong assumption? Please be open to discussion. I'm trying to be fair in the process. I'm just struggling for the best way to address to everyones points. I appreciate any contributions to improve our concept. Thanks in advance! -Keisuke
Thanks Pete, Here is my view to your principles, Ziu, Peter wrote:
Keisuke,
I believe that the most prudent solution needs to take into account the following two principles:
- the repository needs to be able to handle (within the limits of the hardware set) any amount of application contents and associated data for a system (one notional AA).
I fully agree with this and think the protocol choice for bulk data transportation derived from this consideration.
- Something must maintain the notion of the version and integrity of system (via one notional AA), through proper referential integrity and signature.
Yes, something must. However, I think it is arguable that the ACS is the one or we should leave it for the specific implementations. For example, the version numbering model would implicitly include how, who and when will create branches in the versions. I'm not sure if we can safely specify these details as an single standard. -Keisuke
Continueing from the previous post... For the rest of comments from Pete, Ziu, Peter wrote:
In response to your questions:
I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them).
I am not particularly hung up on names right now, that is a refinement issue, and not a defining structure. The issue is whether there should be a porttype which has a method for pushing an entire and complete physical AA into a repository.
So do I.
Here is my take on the issue:
- In the case of an ACS implementation, sending an entire AA imposes a need to "know" about a physical file format. This is contradictory to our statement that "we will not define how an ACS will store it's data".
We will define the archive format, but will not break into the data representation to each of the file contents. I think it's like a defineing TCP packet or SOAP envelope without specifying the format or representation of the payload data.
For example, if my implementation of ACS requires a method in the porttype that requires the acceptance of a physical AA file, then I must parse the AA file into parts in order to store it into the format that my implementation has chosen. Perhaps my AA file is stored in thousands of DB2 or Oracle records, since using one record to store an AA file will most likely fail at some point when too big.
Using the off-the-shelf RDBMS is one of the posibilities and how the record is designed to accommodate the AA file content is out of scope of the specification, just like the internal representation of the repository. Do you believe we need to break into this?
If I had porttypes that allowed me to remotely construct an AA, we can punt on a physical format and an entire physical AA transmission format. Providing we have the appropriate porttypes to remotely construct, inspect, and retrieve parts of an AA, then we only need to define on the wire how to move parts of an AA around, yet we can still maintain the notion of an AA and it's integrity, since the interface that constructed it can enforce it's integrity. This is why Tom has outlined sending the entire AAD (hope that the correct acronym) when replicating. The receiver of the replica can inspect and traverse the AAD to find the parts to pull the file over in chunks... especially if there was "modified date" time stamp info on each individual part, then we could explore the replication model I outlined.
Yes we can define only the Descriptor in XML doc, and we can additionally specify the packet or envelope of the data; this will make easier for future IDEs comform to the ARI and AAF. If we are discussing we should only have ARI but not AAF, it may be feasible, but as soon as we specify the AAD schema, it is a part of the current AAF. So I guess the residue here is if we were to define the physical format in addition to the AAD schema.
- A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far.
- I think this is what Tom has been trying to focus on in his .ppt last meeting. I seemed to have put my physical file comments in the previous question, sorry.
Yes this is my take, too. The only reason why I didn't hit this was no one pointed this obvious argument so far, if it is.
- Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.)
- it is related since defining how parts of an AA are created, accessed, modified, and removed have implications that, in the case of physical file formats, would need to be known by ACS if an ACS impl. decided to just write the received AA file to disk, and then later have to modify it.
Yes, it is related, but I thought still we can discuss this at another occasion.
- Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.)
I am not sure I understand this question. No matter what porttype spec we come up with, as long as we do not create any issues for the IDE's or ant (or any other client type), we should be ok. I think that having the client create one file will have scalability issues to remote clients of ACS for large AAs.
I neither have conceivable reason for this. However, I remember Tom appealed there is (or should) not such IDEs in the previous conversation.
- Or anything else?
That's my take.
I listed as many as topics I can imagine in my post, and can't imagine any more at the moment w.r.t. the AA creation use case. I appreciate comments from anyone. - Keisuke
I generally agree with Pete's comments too. I also think that the specication should provide import and export functions which might support multiple formats. The specification could mandate at least one be supported and others as optional. For instance, it might be good to be able to put/get the contents with compression activated. Just an idea. I would also put the concept of "patches" on the table as it might impact the specification. Keisuke Fukui wrote:
Continueing from the previous post...
For the rest of comments from Pete, Ziu, Peter wrote:
In response to your questions:
I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them).
I am not particularly hung up on names right now, that is a refinement issue, and not a defining structure. The issue is whether there should be a porttype which has a method for pushing an entire and complete physical AA into a repository.
So do I.
Here is my take on the issue:
- In the case of an ACS implementation, sending an entire AA imposes a need to "know" about a physical file format. This is contradictory to our statement that "we will not define how an ACS will store it's data".
We will define the archive format, but will not break into the data representation to each of the file contents. I think it's like a defineing TCP packet or SOAP envelope without specifying the format or representation of the payload data.
For example, if my implementation of ACS requires a method in the porttype that requires the acceptance of a physical AA file, then I must parse the AA file into parts in order to store it into the format that my implementation has chosen. Perhaps my AA file is stored in thousands of DB2 or Oracle records, since using one record to store an AA file will most likely fail at some point when too big.
Using the off-the-shelf RDBMS is one of the posibilities and how the record is designed to accommodate the AA file content is out of scope of the specification, just like the internal representation of the repository. Do you believe we need to break into this?
If I had porttypes that allowed me to remotely construct an AA, we can punt on a physical format and an entire physical AA transmission format. Providing we have the appropriate porttypes to remotely construct, inspect, and retrieve parts of an AA, then we only need to define on the wire how to move parts of an AA around, yet we can still maintain the notion of an AA and it's integrity, since the interface that constructed it can enforce it's integrity. This is why Tom has outlined sending the entire AAD (hope that the correct acronym) when replicating. The receiver of the replica can inspect and traverse the AAD to find the parts to pull the file over in chunks... especially if there was "modified date" time stamp info on each individual part, then we could explore the replication model I outlined.
Yes we can define only the Descriptor in XML doc, and we can additionally specify the packet or envelope of the data; this will make easier for future IDEs comform to the ARI and AAF. If we are discussing we should only have ARI but not AAF, it may be feasible, but as soon as we specify the AAD schema, it is a part of the current AAF. So I guess the residue here is if we were to define the physical format in addition to the AAD schema.
- A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far.
- I think this is what Tom has been trying to focus on in his .ppt last meeting. I seemed to have put my physical file comments in the previous question, sorry.
Yes this is my take, too. The only reason why I didn't hit this was no one pointed this obvious argument so far, if it is.
- Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.)
- it is related since defining how parts of an AA are created, accessed, modified, and removed have implications that, in the case of physical file formats, would need to be known by ACS if an ACS impl. decided to just write the received AA file to disk, and then later have to modify it.
Yes, it is related, but I thought still we can discuss this at another occasion.
- Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.)
I am not sure I understand this question. No matter what porttype spec we come up with, as long as we do not create any issues for the IDE's or ant (or any other client type), we should be ok. I think that having the client create one file will have scalability issues to remote clients of ACS for large AAs.
I neither have conceivable reason for this. However, I remember Tom appealed there is (or should) not such IDEs in the previous conversation.
- Or anything else?
That's my take.
I listed as many as topics I can imagine in my post, and can't imagine any more at the moment w.r.t. the AA creation use case.
I appreciate comments from anyone.
- Keisuke
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
Hi Mike, It's an interesting idea to import/export the archives. I guess it involves in transformation or conversion between XML documents if it is about the AD or DD. It might be possible by using XSLT type of technology. For the rest of the things not in a XML document, still we can explor the conversions between them. As for the put/get, yes it should be able to combined with compression. My idea is to make it a variation to the complete set of the archive. -Keisuke Michael Behrens wrote:
I generally agree with Pete's comments too.
I also think that the specication should provide import and export functions which might support multiple formats. The specification could mandate at least one be supported and others as optional. For instance, it might be good to be able to put/get the contents with compression activated. Just an idea.
I would also put the concept of "patches" on the table as it might impact the specification.
Keisuke Fukui wrote:
Continueing from the previous post...
For the rest of comments from Pete, Ziu, Peter wrote:
In response to your questions:
I'd like to ask everyone which of the below is the real issue we are facing: - Name for the things to be registered; i.e. AA file in my diagram, or Archive description and Application contents file(s) (includes DD) in Tom's one. If this is an issue, I can be so much flexible about how we can call it (them).
I am not particularly hung up on names right now, that is a refinement issue, and not a defining structure. The issue is whether there should be a porttype which has a method for pushing an entire and complete physical AA into a repository.
So do I.
Here is my take on the issue:
- In the case of an ACS implementation, sending an entire AA imposes a need to "know" about a physical file format. This is contradictory to our statement that "we will not define how an ACS will store it's data".
We will define the archive format, but will not break into the data representation to each of the file contents. I think it's like a defineing TCP packet or SOAP envelope without specifying the format or representation of the payload data.
For example, if my implementation of ACS requires a method in the porttype that requires the acceptance of a physical AA file, then I must parse the AA file into parts in order to store it into the format that my implementation has chosen. Perhaps my AA file is stored in thousands of DB2 or Oracle records, since using one record to store an AA file will most likely fail at some point when too big.
Using the off-the-shelf RDBMS is one of the posibilities and how the record is designed to accommodate the AA file content is out of scope of the specification, just like the internal representation of the repository. Do you believe we need to break into this?
If I had porttypes that allowed me to remotely construct an AA, we can punt on a physical format and an entire physical AA transmission format. Providing we have the appropriate porttypes to remotely construct, inspect, and retrieve parts of an AA, then we only need to define on the wire how to move parts of an AA around, yet we can still maintain the notion of an AA and it's integrity, since the interface that constructed it can enforce it's integrity. This is why Tom has outlined sending the entire AAD (hope that the correct acronym) when replicating. The receiver of the replica can inspect and traverse the AAD to find the parts to pull the file over in chunks... especially if there was "modified date" time stamp info on each individual part, then we could explore the replication model I outlined.
Yes we can define only the Descriptor in XML doc, and we can additionally specify the packet or envelope of the data; this will make easier for future IDEs comform to the ARI and AAF. If we are discussing we should only have ARI but not AAF, it may be feasible, but as soon as we specify the AAD schema, it is a part of the current AAF. So I guess the residue here is if we were to define the physical format in addition to the AAD schema.
- A physical format of the archive; a zip is described in the strawman. If this is an issue, we can focus on this topics. However, it is not mentioned as this so far.
- I think this is what Tom has been trying to focus on in his .ppt last meeting. I seemed to have put my physical file comments in the previous question, sorry.
Yes this is my take, too. The only reason why I didn't hit this was no one pointed this obvious argument so far, if it is.
- Partial update of the archive in the repository (It seems to me a separate issue that can be discussed independently.)
- it is related since defining how parts of an AA are created, accessed, modified, and removed have implications that, in the case of physical file formats, would need to be known by ACS if an ACS impl. decided to just write the received AA file to disk, and then later have to modify it.
Yes, it is related, but I thought still we can discuss this at another occasion.
- Assuming IDE products to be bound to ACS specification (IMHO, it's desirable, but the decision remains up to the vendors.)
I am not sure I understand this question. No matter what porttype spec we come up with, as long as we do not create any issues for the IDE's or ant (or any other client type), we should be ok. I think that having the client create one file will have scalability issues to remote clients of ACS for large AAs.
I neither have conceivable reason for this. However, I remember Tom appealed there is (or should) not such IDEs in the previous conversation.
- Or anything else?
That's my take.
I listed as many as topics I can imagine in my post, and can't imagine any more at the moment w.r.t. the AA creation use case.
I appreciate comments from anyone.
- Keisuke
participants (3)
-
Keisuke Fukui -
Michael Behrens -
Ziu, Peter