@(#) LSARC Questions Version 2.0u @(#)LSARC 1.30 07/12/07 __________________________________________________________________ Copyright 2007 Sun Microsystems, Inc. 0. Remind us: 0.1 The case number for this project? LSARC 2008/492 0.2 This questionnaire is for an [X] Inception Review or [ ] Commitment Review 0.3 Name(s) of person(s) answering the questions? Chris Kasso 0.4 Are these case materials considered public or confidential? Public 1. What specifically is the proposal that we are reviewing? 1.1 The case owner will need to put a 1 to 4 paragraph description at the top of the Opinion document. Suggest text for it. Please be specific about deliverable components and their interfaces. This is a sub-project of the Update Center 2 Toolkit project which focuses on the Update Tool GUI, Desktop Notifier and Configuration Extensions. 1.2 Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", "micro" or "patch" change and why? (See the release type definitions in http://sac.eng.sun.com/BestPractices/release_taxonomy.html ) New 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? See the umbrella case for Update Center 2, LSARC/2008/411 3. The plan: 3.1 Who (what groups in what business units) are working on it? The Update Center 2 team in the in Java Enterprise System Engineering department of the Software Infrastructure (SWI) business unit. 3.2 What is the current status? Build 14 of 15 planned builds has been completed. Release of this software is planned for the Glassfish V3 Prelude release in October, 2008. 3.3 Has a design review been done? Yes. 3.4 What Product Approval Committee (PAC) do you expect to approve this project? WAPPAC JESPAC 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? Image Packaging System (IPS or pkg(5)) (PSARC/2008/190) Update Center 2 Toolkit - IPS Enhancements (LSARC/2008/493) 4.2 What non-Sun projects does this project depend upon? Python wxPython OpenSSL 4.3 What other projects depend on this one? Initially Glassfish. Over time other SWI Software Infrastructure) projects will begin using this project. 4.4 What other active projects at Sun are related to your project, and how are they related? See the umbrella case (LSARC/2008/411) 4.5 What future projects should be started or avoided to help your project succeed, and why? 4.6 What open source communities does this project interact with? opensolaris.org - pkg(5) project 5. What technical approach has been selected by the project? 6. How is the project delivered into the system? See LSARC/2008/493 - FSD section 3.1 for the general package overview. http://sac.eng/LSARC/2008/493/inception.materials/FSD.html#section-UC20FSD.IPSEnhancements-3.1ProductPackaging This project delivers the following IPS (format) packages: updatetool: The main GUI and notifier applications. updatetool-data: Delivers category information that is displayed by the GUI. wxpython2.8-minimal: wxPython implementation (minimized) These packages can be delivered by the IPS pkg client, the Java-based Bootstrap and Java API (See LSARC/2008/493 - FSD section 4.5) or the Update Tool GUI (if it had been previously installed (e.g. preconfigured image zip bundle). 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. * Windows XP and Vista on x86 * Mac OS X on PowerPC and x86 * Popular, Recent Linux Distributions on x86 * Solaris 9 and 10 on SPARC and x64 * OpenSolaris 2008.05 and above 7.2 Are Solaris components expected to work on SPARC and x86? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? Yes. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No. 7.4W For Microsoft Windows components, what is the minimal hardware configuration supported (e.g., Pentium with 128mb of memory)? This isn't an issue since any hardware that runs Windows today will be able to run this software. 8. Compatibility and Interoperability See http://wikis.sun.com/display/IpsBestPractices/OS+Platform+Support for information on OS platform support. (Consider a compatibility matrix, if the information is nontrivial.) 8.1W For Microsoft Windows components, what Windows releases does it work on? Client-oriented releases (98/ME/XP/Vista)? Server releases (2000/2003)? Yes, both. 8.2W Does it depend on features and software that exist only in certain versions of Windows, such as networking features not in XP Home? No. 8.1S OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? See http://wikis.sun.com/display/IpsBestPractices/OS+Platform+Support for information on OS platform support. 8.1.2 Does it run on Linux? What distribution(s) and version(s)? See http://wikis.sun.com/display/IpsBestPractices/OS+Platform+Support for information on OS platform support. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? Unknown. 8.2S Do Solaris components depend on OS features not in the core OS (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages or clusters must be installed first (if the "core" set of packages is insufficient)? Do the packages express those dependencies explicitly? See http://wikis.sun.com/display/IpsBestPractices/OS+Platform+Support for S10 Minimum Software Group info: > The Update Tool GUI and Desktop Notifier components require Gnome > desktop support to function properly. Typically, users on Solaris 10 > requiring desktop support have installed the "End User" software group > or greater. You may also add individual packages to the "Core" or > other software group to support the GUI. 8.3 Do Solaris components use any system interfaces, commands, or features not in POSIX or the Single Unix Specification? What is the minimum version of those standards required? (POSIX.1-1990, UNIX98, UNIX2003?) Yes. Python most certainly uses interfaces not in these standards. However, this is deemed to be low risk because it already ships with Solaris. 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base? What is the minimum LSB version required? See answer to 8.3. 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) IPS - see LSARC/2008/190. IPS release numbers have not yet been solidified. The UC2 release is planning to ship with an IPS snapshot. 8.5 What internationalization (I18n) issues are involved? What languages *can* be supported by localization without modifying the base product, whether or not a localization is currently planned? What I18N interfaces will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext(), X/Open catgets(), GNU gettext? What items and interfaces are (or are not) being internationalized? All left to right languages can be supported without modifying the base product. (Caveat - We do restrict the languages to only the one we supply localizations for and as such is an artificial restriction.) What I18N interfaces will the project adhere to? gettext (Solaris). GNU gettext is a superset (AFAIK) and works just fine. Generally everything in the GUI is being internationalized. 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/x86 ABI, POSIX, Open Group standards, IETF RFCs, national or international standards. Include version numbers where applicable. No. 8.7 Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? Multiple user images may exist with earlier or later versions of this project. The desktop notifier should be able to monitor all images for new pkg updates. Running the GUI from one image should be able to manage pkgs in other images. This compatibility depends on the IPS interfaces remaining capable of interacting with older and newer meta-data and repos going forward. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? This project enables the installation and removal of IPS based pkgs. These pkgs, generally created by other projects, fall into this category. This is as designed. On some platforms (e.g. OS X) the product may write messages to a system log (/var/log/system.log) Beyond what is mentioned above the product does not move, disable, delete, circumvent or change any files, components, or services outside the project. 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? Yes. This project accesses Python based interfaces from the IPS project that are not classified yet (PSARC/2008/190). 8.10 What components (e.g., libraries or packages) are shared with other projects or products? See the interface table. 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? OEM relabeling is not supported. User preferences are supported. Preferences are maintained in: Windows: Documents and Settings\\Applicaiton Data\updatetool\ Unix: ~/.updatetool Max OS X: /Library/Application Support/updatetool 8.12 Device Drivers: 8.12.1 Does this project deliver any device drivers? No 8.12.2 Does it conform to the Solaris DDI/DKI (manual sections 9e, 9f, & 9s)? 8.12.3 Does it pass "DDICT" DDI compliance tool (available on Solaris DDK)? 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. See the GUI FSD section 7.1 9.2 Interface Table: Include Imported and Exported Interface Tables showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). Interfaces are not just function calls. Include user interfaces (graphical, browser based, character based), configuration files, XML DTD's, database schemas, network protocols, port numbers, etc. Imported Interfaces Interface Classification Comments ------------------------------------------------------------------------------- IPS API Contracted Project Private PSARC/2008/190 Python 2.4.4 Volatile http://python.org/ wxPython 2.8.8.0 Volatile http://wxpython.org/ GNOME login startup interface Volatile http://standards.freedesktop.org/autostart-spec/autostart-spec-0.5.html OS X login startup interface Volatile http://developer.apple.com/macosx/launchd.html Windows login startup interface Volatile \Start Menu\Programs\Startup Exported Interfaces Interface Classification Comments ------------------------------------------------------------------------------- /bin/updatetool Committed UT executable location /updatetool/bin/updatetool Committed UT executable location updatetool (command name/CLI) Committed See [3][4] updatetool exit codes Committed Updatetool preferences Committed Private See [1] Updatetool IPC Protocol Committed Private See [2] Updatetool log files Not-an-interface /updatetool/bin/updatetoolconfig Committed UT-config exec location updatetoolconfig (command name/CLI)Committed See [5] updatetoolconfig exit codes Committed See [5] updatetoolconfig output Not-an-interface updatetool IPS package Committed Manifest in case dir. Package attributes: org.updatetool,postinstall org.updatetool,postupdate org.updatetool,preremove Committed See [6] Configurator exit codes Committed See [7] var/install/log/config/-.log Not-an-interface See [7] [1] preferences.txt in case directory [2] protocol.txt in case directory [3] See section 7.2.1 of GUI FSD for CLI details. [4] See section 2.1 of the Notifier FSD for CLI details. [5] See section 2.7 of the Notifier FSD for CLI details. [6] Install time config spec section 3.1.1 [7] Install time config spec section 3.1.2 Links to these specs are list in: http://sac.eng/LSARC/2008/492/inception.materials/README.html 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). See GUI FSD section 8. Also see the umbrella case LSARC/2008/411 (one-pager section 4.10.1). Also the file lists in the manifests (see question 9.4). 9.4 Package manifest: The package manifests are included in the case materials in the following files: manifests/updatetool manifests/updatetool-files (file list only) manifests/wxpython2.8-minimal manifests/wxpython2.8-minimal-files (file list only) 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? See section 7.2.1 in GUI FSD See section 2.1 in the Notifier FSD See section 2.7 in the Notifier FSD 10.1S Do they conform to PSARC/1999/645 command syntax guidelines, an extension of the Single Unix Specifications rules? Are any of the "CLIP" extensions to the SUS guidelines used? yes 10.1.1 Is there support for standard forms, e.g. X11(5) manpage's "-display", etc.? If not, why not? No. We haven't found a way to initialize wxPython with a specific DISPLAY. Users can work around this by setting the $DISPLAY env. 10.1.2 Are these options propagated to sub-environments? n/a 10.2 Can it be included in a shell pipeline? How does it use standard input, output and error? Stdout/err are generally redirected to a log unless the --tty option is provided on the command line. CLI syntax errors and --help output will go to the tty expect on Windows where they will be displayed in a dialog. 10.3 Environment Variables: 10.3.1 What environment variables are used? Describe values and semantics. Set: PKG_CLIENT_TIMEOUT= : network socket connect timeout in seconds used by IPS. Read: HTTP_PROXY FTP_PROXY NO_PROXY (not supported yet) LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 10.3.2 What is the default behavior if the environment variable is not set? 10.3.3 What environment variables are set? 10.4 For Solaris, Linux, or other Unix programs, what are their exit status values? What nonzero status values have what meanings? GUI/Notifier: 0 - Success >0 - Failure updatetoolconfig script: * 0 - Success. * 1 - Registration failed because the notifier is already registered. If --force is used 0 is used as the exit code instead of 1. * 1 - Unregistration failed because the notifier is not registered. If --force is used 0 is used as the exit code instead of 1. * 2 - Unsupported/bad CLI option. * >2 - All other errors. 10.5W What inter-component Windows messages are sent or intercepted? None. 10.5S Signals issued? Signals caught? (See "man signal".) What are their semantics? None 10.6 Device drivers directly used (e.g. /dev/audio)? None. 10.7W SYSTEM.INI, WIN.INI or other resource/configuration files or databases? Describe any files used between invocations. 10.7S .rc/defaults files, Java properties, GNOME GConf keys or other resource/configuration files or databases? Describe any files used between invocations. A user based preference file (See 8.11) is maintained. When the user applies the preferences from the GUI or Notifier dialog the preferences file (defaults.cfg) is updated. A platform specific user login start-up task may be registered with the system to start the notifier at user login. 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? On Unix the preferences are stored in a .updatetool directory in ~. The product's logs are also stored in this directory. See the "Implementation Details" section of the Notifier Lifecycle FSD for details about how the notifier uses this directory. 10.9 Does it use any locking files? Does it use Solaris locking facilities? Only one instance (per user and host) of the GUI and the Notifier are allowed to run at once. (e.g. One GUI and one notifier for user A on host B). When the GUI or Notifier are launched they create a host specfic file in a directory in the user's Updatetool preferences directory: ~/.updatetool/lock/nt_lock- (notifier) ~/.updatetool/lock/ut_lock- (GUI) This host specific file contains a port number that the running GUI or notifier is listening on. When a new instance of the GUI/notifier are started it checks for the presence of one of these files. If found it attempts to contact the running instance to verify it is running and it also pings the existing instance to raise itself so that the user sees the existing instance. These lock files are never removed. They only get updated as new instances successfully start. 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? The GUI generally runs on the user's desktop. I can be run remotely with $DISPLAY pointing to the user's desktop. The notifier generally runs in the background. It is started when the user logs into the system and is shutdown when the user logs off the system. 10.11W For each Windows component (EXE, DLL or VxD) identify the name of the component and module identifier (EXE/DLL) or VxD ID (VxD)? If a module provides a plug-compatible replacement for a standard system component, identify the component and its version. Indicate whether VxD IDs are officially registered. updatetool.exe 10.11S Solaris/Linux/Unix Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. N/A (See LSARC/2008/493 for python info) 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? N/A 10.11.2 With what -R options will executables be built? WxPython shared objects: $ORIGIN/../wxWidgets/lib 10.11.3 Does it use any static libraries? No. 10.11.4 What libraries does your project export? None. 10.12 Does your project use or ship database or persistent storage software? If not, skip the rest of this section. No. 10.12.1 What software does it use? N/A 10.12.2 Does it meet the SAC Policy on using standard databases? (see the Database Policy at http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=dbpolicy.bp ) If NO, please provide the reason: [ ] does not meet technical requirements (please specify) [ ] product already shipping with non-compliant technology [ ] customer requires we use a specific database [ ] other (please describe) 10.12.3 Is the database technology available for customer use? 10.12.4 Does the customer have to explicitly manage/administer the technology? 10.13 Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? This project depends on versions of Python (minimized), wxPython (minimized) and IPS which are shipped with the project. These versions must live within the product image. External versions can not be used (as of 2.0). Future versions of the project will support using external version of these dependencies. 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? The Update Tool GUI and its associated desktop notifier application are delivered as a distinct IPS package that can be embedded in a pre-installed installation image, downloaded during initial installation through the initialization component or installed after the fact through the IPS pkg CLI. 11.2 How will the project's deliverables be uninstalled? Using IPS, via an uninstaller, file system remove or using an existing GUI instance.. 11.3 How will the project's deliverables be configured and reconfigured? The project my be preconfigured when included in a pre-installed installation image. Projects using this project (E.g GlassFish) can pass initial config via properties using the UpdateTool Java interfaces (IPS bootstrap interface). See 4.5 in the IPS Enhancements (LSARC/2008/493) FSD. 11.4 Does it need installation within any global system tables? Does your package edit existing files in a common directory (/etc/vfstab for example)? If so, how do you remove your edits when your package is removed? If your package is reinstalled over itself, does it recognize that the edits are already there or does it make all new entries? The notifier can be registered as a user level login start up task. The mechanism used to accomplish this varies by platform and desktop type. Generaly we install a file or executable into an OS specific directory that is used by the desktop to trigger their start at user login. What Microsoft Windows registry entries are created or modified? None. 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? Yes - IPS. We include our own copy in the installation image. 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? N/A - this software doesn't involve the use of pkgadd. The software is fully relocatable. 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? (BASEDIR) Yes. 11.7.1 Has your project changed or introduced any package procedural scripts (postinstall, preremove, etc)? N/A. If YES, are these scripts well-behaved with respect to alternate roots? That is, when these packages are added or removed using -R, do they cause any changes to be made to /? The correct answers are either "No" or "Yes, Yes, and No". 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? N/A. 11.9 How does a new version of your package upgrade a prior version? This is done via the IPS package update capability or via the GUI using the IPS based API. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? Yes. 11.12 How is it started? The GUI is started manually. The notifier can be started manually but generally it is started automaticaly at user login. 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? Indirectly. 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? The GUI will create a log file in ~/.updatetool//{notifier.log, updatetool.log}. The log file will roll over when it reaches 5MB. A maximum of 5 logs files will be maintained. Details: http://wiki.updatecenter.java.net/Wiki.jsp?page=UC20Logging 11.15 Can administration be done from a remote machine? How? Only via remote login. 11.16 Can all GUI administration also be performed without the GUI? How? Yes, installation image properties can be changed using the IPS CLI. GUI specific preferences can be changed by directly editting the defaults.cfg file but this is not advertised in our docs. 11.17 What command or scripting language is used? The implementation uses sh, BAT, python. 11.18 Does the project include runtime license checking? Why? How is it accomplished? How does it cope with changes of the underlying system due to hardware replacement or virtualization? No. 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, technology royalty structure, or open source license requirements? No. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? If not, say "NONE" and remove all this section's subsections. Yes 12.1 If the project includes a GUI (Graphical User Interface), case materials should summarize the GUI's "User Model" in a few pages; that is, the objects that the user sees or must know about, their logical state, and the operations the user may perform on them. See the section 3 of the GUI FSD. 12.2 Do the GUI components share the Look and Feel of their product? In other words, does each component appear to be part of the same product family? Yes. 12.3 Have the GUI components had Human Computer Interaction (HCI) usability consultation? What recommendations were and were not heeded? Minimal HCI interaction. 12.6S What window-system toolkit does your project depend on? wxPython. 12.7S What specific desktop integration work is planned? (GNOME examples: Nautilus icons for new data types, .desktop files to make applications show up in the menus, panel "applets") The notifier can be registered as a login startup task. 12.9S Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? Online help exists. Cut/Paste from text fields are supported. No D&D support. 12.10S When your windows are stretched ("maximized"), do your widgets expand to use the extra screen real estate? Is that part of GUI testing? What happens when you maximize in Xinerama mode? Yes, the widgets expand and shrink as necessary. 12.11S Will it work with remote and/or low-bandwidth displays, such as Sun Rays, VNC viewers, and remote X servers? Yes. 12.12S Desktop Environments: 12.12.1 Does the GUI run correctly under both the default CDE window manager (dtwm) and the default GNOME window manager (metacity?) On Linux systems, does it run with the default KDE window manager? The project works correctly with the WMs supplied on the platforms supported by this release of the project. 12.12.2 Are the GUIs compliant with the style guides for the look-and-feel employed? Should be - some of this we get for free from the wxPython impl. 12.13 Is the application usable with accessibility aids like screen readers and magnifiers? On Windows and Linux and partially on Solaris. Magnifier support should work on all platforms. 12.4W Describe your project's support for User Interface facilities 12.5W Are drag 'n' drop and cut 'n' paste supported where meaningful? Cut and Paste is supported. 12.6W Is each GUI compliant with the Windows Style Guide? To the extend the wxpython implementation is. 12.7W If your software implements any Windows or other PC API or protocol for use by Solaris-based components, what subset of that API or protocol is supported? Do the semantics diverge from those published for that API or protocol? N/A 12.8W If your software provides access to Solaris resources or services to Windows-based clients by wrapping those services in a Windows or other PC API or protocol, what subset of that API or protocol is supported? N/A 12.9W Is it compatible with Windows emulation (such as Wine) or virtualized Windows (such as under VMWare)? If not, what technical aspects preclude compatibility and what would it take to remove the incompatibility? Yes. 12.10W Does it run well in remote Windows display environments such as Windows RDP, Sun Secure Global Desktop (SGD, aka Tarantella), or Citrix? If not, what technical aspects cause problems and what would it take to resolve them? Unknown. 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. See section 2.2 of the FSD. 13.1 Exported Library APIs and ABIs exposed to customers 13.1.1 The name of the library 13.1.2 The installation location for the library 13.1.3 The prefix(es) reserved for use by the library and its header files. 13.1.4 The syntax and semantics of every symbol exported by the library. 13.1.5 Compile time symbols (#defines or #ifdefs) defined by the project? 13.1.6 Are there any library or headerfile symbols that don't start with one of those prefixes? 13.2 Protocols (public or private, including RPCs) 13.3 Drag and Drop: what objects and what are the semantics? 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? 13.5 Files used as an interface, e.g. Resources, config files, etc. 13.6 Significant file formats, names, syntax, and semantics? Is there an /etc/magic entry for any new file format? What will file(1) say? 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? 13.9 Other External Interfaces? 13.10 Brainstorming Significant Internal Interfaces 13.11 Protocols (public or private) 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions 13.13 Files and their Formats 13.14 Do any internal interfaces save state across invocations? 13.15 Other Internal Interfaces? 14. Questions for Every Interface: These questions should be asked for every one of the project's interfaces; the answers are therefore often listed in Section 9.2 (Don't repeat.) Only the interesting answers are normally discussed. 14.1 Propose the stability/commitment classification of the interface -- Committed (formerly Public, Stable or Standard), Uncommitted (formerly Unstable), Volatile, Project Private, etc. -- per the SAC Interface Taxonomy document at http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? 14.3.2 Is the specification complete enough for a re-implementation? 14.3.3 Will the project deliver to customers documentation for the interface? 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? 14.4 Interface Versioning and Projected Evolution 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? 14.4.3 For Microsoft Windows components that install on top of an existing product (such as PC-X on top of PC-NFSpro): are there common files that should only be upgraded if the files being installed have a new version? 15. Performance and Scalability: 15.1 What are the performance goals of the project? How were they evaluated (or how will they be)? On what type of test platform? How will performance regressions be identified? See the umbrella case (LSARC/2008/411) and the IPS case (PSARC/2008/190) 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? 15.3 Resource Consumption: 15.3.1 Attempt to describe resource consumption scaling, even crudely. For example, if each client consumes 1MB of memory, you could say: Memory_required = 1MB * Nclients 15.3.2 Which resources are likely to be bottlenecks? Memory, disk access speed, CPU time. 15.4 Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? Is it prepared for multi-thread & multi-core systems like Niagara and Opteron? 15.6 What is the impact on system performance (positive or negative)? These components do not have a significant impact on overall system performance. 15.6.1 What is the average memory usage or working set of this component? 15.6.2W How much of this is locked down? 15.6.3W What system resources are consumed by each component under Windows? 15.6.2S How much of this is shared/sharable by other apps? 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? The notifier wakes up hourly to determine if it should check for new updates. If it is not time to check for updates it goes back to sleep. The notifier attempts to check for updates based on a frequency established by the user (never, daily, weekly or monthly). The update check occurs base on the established interval, the last update check time and the wall clock time. The notifier attempts to perform the check at the correct time (if the user is logged in) regardless of whether the system hibernated (or the user logged out and in) between checks. 15.8 Will it require large files/databases (for example, new fonts)? No. 15.9 Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? No. 15.10 What are the project's effects on boot time requirements? None. If the notifier is registered as a login start task the user's log in could by impacted by the notifier start up adding load to the system. 16. Security: Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. The GUI depends on IPS so it depends on the security features built into IPS. Generally security occurs at the filesystem level. For example a user can not update an installation image owned by another user unless the filesystem permissions allow it. 16.1 What security issues do you address in your project? None. 16.2 What security concerns might customers or reviewers have? Unknown. 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? None 16.4 How are particularly security-critical data like passwords treated? The GUI preferences allow the user to establish a proxy that requires authentication. The proxy username/passwd are stored in the clear in the defaults.cfg file in the preferences directory. The permissions of this file are 600. 17. Availability and Serviceability 17.1 How will it respond to failures? (Does it ever require reboot? Can it lock up? Is there a way for the user to "unstick it"?) Since the GUI uses IPS to talk to a remote repository a network outage could create issues for the GUI. The GUI will timeout when a network operation fails to complete. 17.2 How does your project deal with network failures (including partition and re-integration)? Network operations will use a timeout to avoid locking up the tool. 17.3 Can it save and restore state? Is any special action required if the filesystem is rolled-back to previous state (such as via ZFS or other filesystem snapshot technologies)? This mostly depends on how IPS handles cases where the filesystem is rolled-back. 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? Mostly depends on IPS behavior. The GUI/notifier locks are never removed by design. New instances will attempt to validate the locks by contacting a running instance. If a connection to a running instance can not be made the new instance takes ownership of the lock 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng.sun.com/)? 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? Yes. The Windows related changes to IPS provide for upgrading files that have executable locks by moving the existing file aside and then deleting it later. Also, files that are locked and cannot be modified are detected before an update and the updated is terminated. 17.7 How will patches be installed? As IPS updates. 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, Microsoft Windows, MacOS X, AIX, HP/UX, etc.)? Yes. That is one of the main points of this project. 18.2 How does it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? Java and Python handle this transparently. 18.3 How will the project provide services to other projects? 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? None. 18.3.2 Current or planned Java Beans, especially J2EE? None. 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) The IPS server interface is REST-based. 18.4 What is its relationship (or difficulties) with . . . 18.4.1 the Internet? Web Services? 18.4.2 Java? J2EE? Application Servers? 18.4.3 "Network of Things" (thin clients, portable devices, cell phones, wireless networking, kitchen appliances with IP addresses?) 18.4.4 Multimedia? 18.4.5 Networked storage (SANs, NAS) 18.4.5 Infiniband? 18.4.6 Network identity services? 18.4.7 Virtualized environments (Xen, Zones, VMWare)? 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) None. Any issues outstanding from previous reviews (or the case's mail archive)? None. 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc See FSD. 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory.