Issue 5969: The install and uninstall operations should be decoupled (deployment-ftf) Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com) Nature: Uncategorized Issue Severity: Summary: The install and uninstall operations should be decoupled from the XML parsing interface. There may be systems that don't offer this capability of a visible XML parser but still need the capability to install and uninstall Resolution: Revised Text: Actions taken: June 18, 2003: received issue Discussion: Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. This is to split the interface in question into uninstallation/ installation and XML parsing features at PIM level. They may be mapped on a joint interface at PSM level. Since a concrete text proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF End of Annotations:===== Subject: Deployment Issues To: issues@omg.org Cc: deployment-ftf@omg.org, swradio@omg.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Gerald_L_Bickle@raytheon.com Date: Wed, 18 Jun 2003 08:35:48 -0500 X-MIMETrack: Serialize by Router on NotesServer3/HDC(Release 5.0.12 |February 13, 2003) at 06/18/2003 08:38:39 AM X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5IDjfkM021179 Initial Deployment Issues: 5. The install and uninstall operations should be decoupled from the XML parsing interface. There may be systems that don't offer this capability of a visible XML parser but still need the capability to install and uninstall. That's all for now. Jerry Bickle Senior Principal Software Engineer Network Centric Systems 1010 Production Rd Fort Wayne, IN 46808-4711 260-429-6280 260-429-5060 Fax Subject: Proposed resolution for issue 5969 Date: Wed, 20 Aug 2003 10:45:32 -0400 Thread-Topic: Proposed resolution for issue 5969 Thread-Index: AcNnKbU/y+cwiHmvTxK48fGbZ5epPg== From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h7KEjPe4031409 This issue is a duplicate of 5961: the newly introduced createPackage operation allows to install packages in a repository that does not support XML parsing. X-Dreamscape-Track-Mars-A: 230-33-181-66.ip.us.tachyon.net [66.181.33.230] X-Dreamscape-Track-Mars-B: Wed, 20 Aug 2003 10:53:13 -0400 (EDT) Date: Wed, 20 Aug 2003 10:53:29 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: "Pilhofer, Frank" CC: deployment-ftf@omg.org Subject: Re: Proposed resolution for issue 5969 Pilhofer, Frank wrote: This issue is a duplicate of 5961: the newly introduced createPackage operation allows to install packages in a repository that does not support XML parsing. We currently have no compliance point that allows a repository to not support parsing. Are you proposing one? I could imagine that an implementation/product would have the option of configuring out this capability (to make a smaller footprint), but a product that could not parse the XML should not be compliant. Jim Subject: RE: Proposed resolution for issue 5969 Date: Wed, 20 Aug 2003 10:58:23 -0400 Thread-Topic: Proposed resolution for issue 5969 Thread-Index: AcNnKtD9QtlUGBI0SZSXtnti5ScvZgAAESMg From: "Pilhofer, Frank" To: "Kulp, Jim" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h7KEwDe4032545 > > >This issue is a duplicate of 5961: the newly introduced createPackage > >operation allows to install packages in a repository that does not > >support XML parsing. > > > We currently have no compliance point that allows a repository to not > support parsing. Are you proposing one? I could imagine that an > implementation/product would have the option of configuring out this > capability (to make a smaller footprint), but a product that could not > parse the XML should not be compliant. > I agree. PSMs have the option of defining the "installPackage" operation an optional compliance point. The PSM for CCM should not (i.e. it should be mandatory in the PSM for CCM). Date: Wed, 20 Aug 2003 18:17:10 +0200 From: Andreas Hoffmann Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: de, en, en-us, en-gb To: James Kulp CC: "Pilhofer, Frank" , deployment-ftf@omg.org Subject: Re: Proposed resolution for issue 5969 James Kulp wrote: Pilhofer, Frank wrote: This issue is a duplicate of 5961: the newly introduced createPackage operation allows to install packages in a repository that does not support XML parsing. We currently have no compliance point that allows a repository to not support parsing. Are you proposing one? I could imagine that an implementation/product would have the option of configuring out this capability (to make a smaller footprint), but a product that could not parse the XML should not be compliant. I guess the ability to parse XML should be mandatory to be compliant. Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ==================================================================== X-Dreamscape-Track-Mars-A: [192.233.20.56] X-Dreamscape-Track-Mars-B: Tue, 21 Oct 2003 18:55:37 -0400 (EDT) Date: Tue, 21 Oct 2003 18:55:31 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en,pdf To: deployment-ftf@omg.org Subject: DIscussion of issue 5969: install/uninstall Here is the issue: Issue 5969: The install and uninstall operations should be decoupled (deployment-ftf) The install and uninstall operations should be decoupled from the XML parsing interface. There may be systems that don't offer this capability of a visible XML parser but still need the capability to install and uninstall Here are my comments: The new createPackage operation defined in the resolution to issue 5961 was specifically designed to perform a subset of the install operation: namely to accept a component package in the form of the IDL-defined ComponentPackageDescription runtime data structure rather than in the form of a zip'd archive of XML files and compiled binaries. Thus any client could decide to never request parsing (and thus either do it itself or do it offline). The "deleteConfiguration" is indeed unrelated to parsing and will remove package configurations whether they originated with installPackage, createPackage, or createConfiguration. The only method that has anything to do with "parsing" is installPackage. Compliant implementations of the repository manager could offer a configuration option to eliminate the parsing code from the implementation (i.e. disabling the installPackage operation), but removing it from the specification would be the elimination of a major feature that supports the fundamental interchange of components. At the last OMG meeting, Gerry proposed discussed the possibility of breaking this interface into two parts to make a "simple inner core" and a larger complete repository manager that inherited the "simple inner core". The solution to this "lightweight" repository manager request could be one of these: 1. Leave the spec/interface alone, but note that implementations can have subset implementations to be leaner if they do not care about introducing standard interoperable components (i.e. two ways to run it, two different implementations etc.). Return errors from some operations in this mode. 2. Change the spec to have a new compliance point that defined some operations to return errors. Sort of "lightweight repository manager". 3. Change the spec/model to have a new interface and a new compliance point that is a subset of the current interface (inherited by the full interface?) (which operations removed?). Jim Date: Tue, 06 Apr 2004 18:47:59 -0400 From: James Kulp Organization: Mercury Computer Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5.1) Gecko/20031120 X-Accept-Language: en,pdf To: Andreas Hoffmann CC: Deployment FTF Subject: Re: Deployment FTF work assignments -- issue 5969 Andreas Hoffmann wrote: Hi FTF members, I tried to collect the currently open work assignments for resolving open FTF issues: - issue 6040 and 6043: assigned to Francis - issue 6266: assigned to Manfred - issue 5969: assigned to Jim This also relates to the additional discussion at the last OMG meeting about "flattened deployment descriptors" that Jerry raised. We discussed having a more efficient form of component descriptors that would also avoid XML parsing. Discussion: This issue 5969 is requesting that the repository manager interface be split so that the operations that require XML parsing be made into a separate interface. This is actually a single install operation, since there is no XML-using "uninstall", only a generic "deleteConfiguration". I believe Jerry intended to have a base interface without the install/uninstall, and then a derived interface that included them. The motivation was to avoid making XML parsing part of a compliant system. The problem with this is that we are defining a compliant system that has no interoperability of components, which is fundamental to any component system. If you can't send a standardized packaged component to be added to a system, then you do not have a component system. Also, since we have the modularity of 4 compliance points, anyone can provide their own proprietary repository manager (or have none at all), and still retain the other compliance points. Presumably this is all about footprint, since the actual code to parse the XML can be easily and automatically generated from the UML models - thus there is no issue about this being "extra work" to write the code. The available parser-generator currently generates code for the DOM API. It could just as easily generate very specific C code from the model and make the parser footprint very efficient and compact. But some people's experience with XML parsing is bad: big and slow. Any implementation on a platform that used shared libraries (dlls) could easily arrange for the XML parsing code library to only be loaded if it was used. Any implementation on a platform that supported manual loading of libraries (like vxWorks) could easily load the appropriate library on first use (if ever). Any implementation that supported starting processes could start a XML-parsing subprocess to do this work. Thus the hard core of the footprint issue is only when you can't afford the space on disk/flash (certainly less than 1MB, maybe much less) for the code, or you can't afford a temporary use of memory during component/application installation. Neither CCM or SCA allows for this, and this D&C specification allows mixing customized repository managers with the 3 other compliant subsystems. It is easy to imagine an implementation of the compliant repository manager that can be down-configured to return a not-implemented error for the one install operation for particular footprint-sensitive installations. The IDL generated for this one operation does not generate any IDL for new data structures -- the operation simply has two string arguments. Thus the memory optimization could be done easily via configuration rather than generating a compliance point that changes exactly one operation. Here is my opinion and suggested resolution of this issue: 1. Raise an new issue on the topic of requiring acceptance of CORBA-codec-encoded metadata files as equivalent to XML (e.g. any file that can now be XML can be also codec-encoded). This allows anyone to generate or translate any component packages into this leaner data format and avoid any XML parsing at installation time. Any user or organization can do this offline to prevent having XML required to be parsed "in the field". This "flattened descriptor" feature can significantly reduce the overhead of parsing XML. It allows such flattened descriptors to be compliant. It does not remove XML as an interoperable format from CCM. 2. Raise an issue in the LwCCM FTF that requests that a LwCCM is only required to accept the binary version. LwCCM is based on CCM+D&C, and can easily add this as a restriction. This solution puts the restriction in the right place: the embedded profile for CCM (+D&C), and it allows for compliant, flattened, interoperable, binary descriptors. It does in fact create a compliance point for it: a LwCCM repository manager. 3. Close this particular issue with no action, leaving the compliant repository manager as is, but anticipating the above changes to address the code issue. Jim - issue 6265, 6269, 6435, 6599 further explanation needed from Jerry - issue 6436: Jim is asked to raise an issue about an improved interface covering a solution for this issue - issue 6597: assigned to Jim (modifying the interface between nodes and target manager) - issue 6598: assigned to all, David and Jerry are encouraged to provide further details of the problem I'd like to ask all to think about the open issues. In particular, it would be nice of those who had accepted work assignments could prepare a solution outline for the upcoming telecon at next Wednesday. Thanks in advance. Regards Andreas ==================================================================== Andreas Hoffmann Fraunhofer FOKUS - Research Institute for Open Communication Systems Kaiserin-Augusta-Allee 31 D - 10589 Berlin Phone: +49 30 3463-7392 Fax: +49 30 3463-8392 Email: andreas.hoffmann@fokus.fraunhofer.de ====================================================================