openSUSE:Libzypp application layer
tagline: From openSUSE
This document describes the roles and interaction of libzypp (the software management back-end), the UIs (user interfaces; the YaST Qt/NCurses/Gtk UIs and zypper) and the glue code between them. It considers bindings to popular scripting languages (currently: Perl, Python, Ruby) into account.
Roles and Terminology
libzypp is designed to be a general purpose library for package management. Being a library, libzypp is not supposed to have built-in application business logic. It is not supposed to make too many assumptions how data are handled, and it should not impose any restrictions on the application that uses it based on such assumptions.
"UI" ("User Interface") is a term that has been used in quite fuzzy ways in previous discussions about libzypp. It was used for both the user visible front-ends and the application layer.
In this document, "UI" refers to any of:
- The YaST package selector widget of the Qt/NCurses/Gtk UI toolkits, including its variations like the patch selector or the pattern selector
- Language bindings
Not necessarily a UI but an application in its broadest sense.
To some very limited extent, "UI" also includes the YaST dialogs that make use of the package selector widgets (sw_single.ycp) and the dialogs that handle repositories.
It is important to note that the package selector widgets are also part of a general purpose library: The YaST UI. Thus, they cannot store any status information because there is no application layer in that library, either.
The application layer (or "app layer") is the glue code that connects the two extremes: libzypp and the UIs. It could live separately, but for easier handling it has been an add-on to libzypp in a separate directory libzypp/ui .
libzypp/app would be a more fitting name, but changing it consistently would mean a lot of changes to existing code that uses it. That said, libzypp/app might exist internally to implement non strictly user interface related glue code.
The UI (in particular the package selector widgets) cannot store any information that lives any longer than their dialogs are visible on screen. In particular, they cannot initialize any handles to things like a zypp pool etc. or repositories. The life time of such information needs to be as long as the calling application is active, which is much longer than those widgets are visible.
In existing code, the YCP application sets up repositories and thus initializes zypp objects like the pool that holds zypp objects like resolvables etc. Even though libzypp can handle any number of pools, for application purposes there is always exactly one pool.
Communication between the YCP application and the C++ package selector widgets is very limited (almost nonexistent). In particular, the YCP application cannot create a pool and pass a handle to that pool to the C++ package selector or vice versa.
Thus, for all important objects like pool or similar, there must be a singleton object for each that can easily be accessed from both the YCP code (via package bindings) and from the package selectors. Those singleton objects should live in the app layer.