@(#) LSARC Questions Version 2.0t @(#)LSARC 1.29 05/10/02 __________________________________________________________________ Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. __________________________________________________________________ 0. Remind us: 0.1 The case number for this project? LSARC 2007/431 0.2 This questionnaire is for an [X] Inception Review or [ ] Commitment Review 0.3 Name(s) of person(s) answering the questions? Mayuresh Nirhali 1. What specifically is the proposal that we are reviewing? Integrating DBI PostgreSQL Interface for Perl in Solaris 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. PostgreSQL version 8.1 was integrated into Nevada & S10u2 in Spring 2006. The core product does not include any interface with Perl. The DBD::Pg driver, that is the PostgreSQL DBI interface will allow perl programs to work with PostgreSQL database. This project aims at integrating the DBD::Pg driver into Solaris. 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", or "micro" change and why? (See the document in /shared/sac/doc/release.taxonomy.) This is a new product. 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? Inclusion of DBD::Pg and DBI perl modules would strengthen Solaris as Out-of-the-Box platform for Perl-Postgres application developers. Considering the amount of perl developers use Postgres on Solaris, this will increase the Postgres offering on Solaris significantly. 3. The plan: 3.1 Who (what groups in what business units) are working on it? Solaris Revenue Product Engineering (engineering resources) and the Database Technology Group (strategy). 3.2 What is the current status? We are ready to integrate Perl DBI 1.58 and DBD::Pg 1.49 into Solaris. 3.3 Has a design review been done? PgAdmin III is open source, and have their own review process. We suspect much of the code has gone through fairly thorough review -- it is a mature open source community. 3.4 What Product Approval Committee (PAC) do you expect to approve this project? DB PAC 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)? None. 4.2 What non-Sun projects does this project depend upon? None. 4.3 What other projects depend on this one? None. 4.4 What other active projects at Sun are related to your project, and how are they related? None 4.5 What future projects should be started or avoided to help your project succeed, and why? None. 5. What technical approach has been selected by the project? We currently support postgreSQL, a fully-fledged enterprise database. However, postgres currently cannot be used as backend for perl applications. The generic db interface (DBI) and postgres specific driver (DBD::Pg) bridge this gap and strenghten postgres offering on Solaris. 6. How is the project delivered into the system? Is it bundled or unbundled? Bundled What are your delivery vehicles (WOS, CTEAM...) WOS Identify package abbreviations, directory names, library names, databases, etc. Please see package map (pkgmap.txt, in case materials) 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. None. 7.2 Are Solaris components expected to work on SPARC and Intel? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? None. Already ported to Solaris by the perl community. The case is just for integration. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No 8. Compatibility and Interoperability (Consider a compatibility matrix, if the information is nontrivial.) 8.1 OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? Solaris 10 8.1.2 Does it run on Linux? What distribution(s)n and version(s)? No. We are not shipping the Linux version. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? None. 8.2S Do Solaris components depend on kernel features not in the default kernel (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? No 8.3 Do Solaris components use any system interfaces, commands, or features not in X/Open CAE SUSv2 and XNS5? No 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base 1.3? N/A 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.) LSARC/2006/655 - PostgreSQL 8.2 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? None 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/Intel ABI, OMG/CORBA, POSIX, SVID, XPG (X/Open Portability Guide), RFCs, national or international standards. Include version numbers. None 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? Both DBD::Pg and DBI are perl modules. Different versions of both these products can co-exist on the machine. By default they will be linked to /usr/bin/perl. They can also be linked to other perl versions by including them in the perl INC path. Similarly, /usr/bin/perl can include alternate DBD::Pg and DBI path. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? No 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? No 8.10 What components (e.g., libraries or packages) are shared with other projects or products? None 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? No. No customization possible. 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)? N/A 8.12.3 Does it pass "DDICT" DDI compliance tool (available on Solaris DDK)? N/A 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. |<- Scope of DBI ->| .-. .--------------. .-------------. .-------. | |---| XYZ Driver |---| XYZ Engine | | Perl | | | `--------------' `-------------' | script| |A| |D| .--------------. .-------------. | using |--|P|--|B|---|Oracle Driver |---|Oracle Engine| | DBI | |I| |I| `--------------' `-------------' | API | | |... |methods| | |... Other drivers `-------' | |... `-' From the above diagram, We already have perl scripting language and Postgres engine available in Solaris. With this case, we would include the DBI and Postgres specific driver (DBD::Pg driver) to provide connectivity between perl and postgres backend. 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 schemas, network protocols, port numbers, etc. See interfaces.txt, included with case materials EXPORTED INTERFACES: Proposed Specified Former Stability Interface Stability in what Classification Name Classification document? or Other Comments ------------------ ------------- -------------- -------------------- Your project will not be easily reviewed without information here ------------------ ------------- -------------- -------------------- IMPORTED INTERFACES: Proposed Specified in Former Stability, Interface New Stability what case no. Contract Number, Name Classification &/or document? or Other Comments ------------------ -------------- -------------- -------------------- Your project will not be easily reviewed without information here ------------------ ------------- -------------- -------------------- 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). 2 packages will be added. 1. SUNWpmdbi 2. SUNWpmdbdpg 9.4 Package manifest: See pkginfo.txt, pkgmap.txt in the case material 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? N/A. 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? 10.1.1 Is there support for standard forms, e.g. X11(7) manpage's "-display", etc.? If not, why not? N/A 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? N/A. Such behavior is inherited from perl. 10.3 Environment Variables: N/A 10.3.1 What environment variables are used? Describe values and semantics. 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 programs, what are their exit status values? What nonzero status values have what meanings? N/A. Inherited from Perl. 10.5S Signals issued? Signals caught? (See "man(5) signal".) What are their semantics? 10.6 Device drivers directly used (e.g. /dev/audio)? N/A 10.7S .rc/defaults files, Java properties, GNOME GConf keys or other resource/configuration files or databases? N/A Describe any files used between invocations. N/A 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? No 10.9 Does it use any locking files? Does it use Solaris locking facilities? No 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? N/A. Such behavior is inherited from perl. 10.11S Solaris 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. There are perl modules. 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? 10.11.2 With what -R options will executables be built? 10.11.3 Does it use any static libraries? 10.11.4 What libraries does your project export? 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? 10.12.2 Does it meet the SAC Policy on using standard databases? (see the Database Policy at http://sac.eng/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? 11. System Administration Interfaces: Please see section 3 of the functional spec for more information about how DBD::Pg will be installed and configured. 11.1 How will the project's deliverables be installed? pkgadd 11.2 How will the project's deliverables be uninstalled? pkgrm 11.3 How will the project's deliverables be configured and reconfigured? N/A. No configuration required. 11.4 Does it need installation within any global system tables? No 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? N/A 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? No 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? Yes. 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)? No. 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)? Both DBD::Pg and DBI packages will be installed within perl install directories. 11.9 How does a new version of your package upgrade a prior version? The new packages can replace the older ones. 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. SUNWpmdbi is a generic interface for all database system specific drivers such as MySQL, DB2 etc. 11.12 How is it started? For a daemon: does it use inetd? If not, why not? N/A. It is perl module and will be invoked by perl internally. 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? No 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? None 11.15 Can administration be done from a remote machine? How? N/A 11.16 Can all GUI administration also be performed without the GUI? How? N/A 11.17 What command or scripting language is used? perl 11.18 Does the project include runtime license checking? How is it accomplished? No 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, or technology royalty structure? Since this is based on open source technology, not all changes can be controlled. The architecture *may* change in unexpected ways. Both DBD::Pg and DBI will manage this by providing a stable release of a regularly changing product. 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. NONE 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. 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) None 13.3 Drag and Drop: what objects and what are the semantics? None 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? None 13.5 Files used as an interface, e.g. Resources, config files, etc.) None 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? N/A 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) None 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? N/A 13.9 Other External Interfaces? None 13.10 Brainstorming Significant Internal Interfaces None 13.11 Protocols (public or private) None 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions None 13.13 Files None 13.14 Do any internal interfaces save state across invocations? No 13.15 Other Internal Interfaces? None 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 -- "Standard", "Stable" (formerly Public), "Evolving", "Unstable" (intentionally Uncommitted), Contract Private, etc. -- per the SAC Interface Taxonomy document in /shared/sac/doc/interface.taxonomy See InterfaceTable.txt in case materials. 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. Both DBD::Pg and DBI are managed by the perl community. Interfaces may change in future and a new version would be released. Solaris should upgrade to new version in such a case. 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? Both DBD::Pg driver and DBI have man entries. 14.3.2 Is the specification complete enough for a re-implementation? Yes 14.3.3 Will the project deliver to customers documentation for the interface? Yes 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? Yes. Being open source project, all the documents are generally available 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. N/A 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? N/A 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? N/A 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? N/A 15.3 Resource Consumption: N/A. The behavior is inherited from Perl. 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? 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? N/A 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? N/A. Both DBD::Pg and DBI are perl modules. 15.6 What is the impact on system performance (positive or negative)? No Impact. 15.6.1 What is the average memory usage or working set of this component? 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? N/A 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? N/A. Such behavior is inherited from Perl. 15.10 What are the project's effects on boot time requirements? None 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/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. Both DBD:;Pg and DBI are perl modules. Security features of Perl will be applicable here. Neither DBD::Pg nor DBI expose pose any security concerns of their own. 16.1 What security issues do you address in your project? 16.2 What security concerns might customers or reviewers have? 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? 16.4 How are particularly security-critical data like passwords treated? 17. Availability and Serviceability 17.1 How will it respond to failures? (Does it ever require reboot? The behavior is inherited from Perl. Can it lock up? Is there a way for the user to "unstick it"?) 17.2 How does your project deal with network failures (including partition and re-integration)? The behavior is inherited from Perl. 17.3 Can it save and restore state? N/A 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? N/A 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng/) No 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? Yes 17.7 How will patches be installed? patch tools 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, perhaps HP/UX, Microsoft Windows, AIX, etc.)? Both DBD:;Pg and DBI are perl modules and they are available on all the platform that is supported by perl. 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? The behavior is inherited from Perl. 18.3 How will the project provide services to other projects? The project will enable the perl apps to use Postgres as backend. 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? N/A 18.3.2 Current or planned Java Beans, especially J2EE? N/A 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) N/A 18.4 What is its relationship (or difficulties) with . . . N/A. Both DBD::Pg and DBI are perl modules. 18.4.1 the Internet? Web Services? 18.4.2 Java? J2EE? Application Servers? 18.4.3 "Network of Things" (thin clients, portable devices, 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? 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) Any issues outstanding from previous reviews (or the case's mail archive)? 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc interfaces.txt pkgmap.txt 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? 24 Hours, 1 person 20.3.2 Do you think it was time well spent? Yes 20.3.3 How many engineer hours went into answering this questionnaire alone? 5 Hours 20.3.4 Comments on this questionnaire should be mailed to lsarc-chair@sac.eng. 20.3.5 Comments on your case owner, the review process, or the experience may be placed here if they're not too personal, may be mailed to the chair or arc-chairs@sac, or may be expressed to John Plocher (x87604), Cheryl Bisque (x51457) or Rob Gingell (x85555).