Hi again, Sebastien. (reply 3 of 3)
On 03/04/10 08:17, Sebastien Roy wrote: > Hi Jack, > > On 03/ 3/10 04:25 PM, Jack Schwartz wrote: >> On 03/03/10 07:26, Sebastien Roy wrote: >>> On 02/26/10 01:17 AM, Frank Che wrote: >>>> ------------------------+-------------+---------------------------------- >>>> >>>> >>>> ddu_devscan() | Uncommitted | DDU library API [2] >>>> ------------------------+-------------+---------------------------------- >>>> >>>> >>>> ddu_package_lookup() | Uncommitted | DDU library API [2] >>>> ddu_build_repo_list() | | >>>> ddu_install_package() | | >>>> ------------------------+-------------+---------------------------------- >>>> >>>> >>>> ddu_repo_object | Uncommitted | DDU library object [2] >>>> ddu_package_object | | >>>> ddu_dev_data | | >>>> ------------------------+-------------+---------------------------------- >>>> >>>> >>> >>> What about the library itself? Is it a C library, a python module, >>> something else...? >> The library interfaces are implemented in python. The interface modules >> call other python and shell scripts, and C programs, all delivered as >> part of the library. > > Python objects and functions don't magically appear in a program's > namespace, right? What does a program have to do to import these > things? It would seem that whatever that is in the set of exported > interfaces. Being python, one imports the modules, or else imports functions and classes from a module. For example: from DDU.ddu_function import ddu_build_repo_list So make the python modules themselves part of the interface? This makes sense, as if these change, the programs which reference them will break. >>> Based on the materials, I don't understand the semantics of >>> /usr/bin/ddu --silent. Basically, I don't grok section 2.1 of your >>> "programming interface spec" (and it seems to be more than a >>> programming interface spec). You explain when --silent is used, but >>> not what it does. This seems central to the proposal, and I'd like to >>> understand this. >> The programming interface spec was written to complement the functional >> interface spec for the Driver Update project. The latter shows the >> higher-level functionality and addresses what silent mode is. I suggest >> the functional interface spec for Driver Update be moved into the case >> materials as well, for added context. >> >> For now, it is here: >> http://hub.opensolaris.org/bin/download/Project+caiman/Driver_Update/du%2Dfunc%2Dspec.txt >> >> > > Yes, this would help. > >> >> The GUI DDU is invoked in silent mode on the live CD, to check for >> missing drivers and install them in the background. If additional >> drivers are still missing, the DDU pops up a window to tell the user, >> and to offer to display the GUI for manual action. > > This makes sense, thanks for the explanation. Why is there not an > equivalent check done in the background in the text-based installer? The lack of a non-windows environment to cleanly pop up a notification window is why the text-installer doesn't have a silent mode. Instead, the text-mode UI will be invoked by the start menu; similar to the start menu on S10, there is a menu item for running the installer, and there is another for running the text-mode DDU UI. Thanks, Jack > > Thanks, > -Seb
