I am trying to collect/brainstorm AIs and ideas to be done on the ZYpp API in the near future. Please give me feedback so that we can turn this into a real plan. Please be concrete. libzypp solves a complex problem and we want to get rid of the accidental complexity we introduced ourselves. So don't just complain but offer alternative ways of doing it, compare it with other APIs (deb, Yum, paludis) For example, paludis has a big API: http://paludis.pioto.org/api/cplusplus/annotated.html but it has clear starting points: http://paludis.pioto.org/api/cplusplus/index.html however the examples are also complex: http://paludis.pioto.org/api/cplusplus/example_contents_8cc-example.html The goals/ideas are: G1 Easier to use API, simpler, smaller (even in C++) Easier to offer as script API (ie: api.installPackage("foo") done ) Ideas about G1: * Make the API small by default. Incrementally powerful ie: if you don't set anything, there are defaults for everything. You start with installPackage("foo") but you can start adding callbacks as you need it -> For example, Trust callbacks, include the zypper handlers by default in ZYpp, so that if you don't set any handler, you get asked on the console by default => allows to implement a client in few lines. Think about including default handlers for everything * don't expose internal APIs as APIs (review what is possible) * get rid of some classes? => * Make the API less "global" If we need to lock, we can integrate the InterProcessMutex prototype or boost::interprocess mutex in RepoManager, commit() and other places. * Make the lifecycle more natural, some stuff confusing: getZYpp() what is a ZYpp? ZYpp::commit() -> operates on Pool, what does it commit? Don't shot me, just brainstorming as I type: Context ctx; t = ctx.getTransaction() t.installBy("foo") t.commit() Transactions can be moved around, compared, printed, exported, imported. etc. Q: repository management? Would that result in a bloated class? how to get all the callbacks unified? May this be a parallel API based on the zypper usecase? May this API be exposed in C? This may be not feasible at all. Right now, out states are stored in unique global pool to avoid Resolvables to store the pool pointer and save memory G2 Less SUSE specific Make easy for MeeGo, ArkLinux, Fedora, etc to use our library. Ideas about G2: * Finish Fedora testing and compatibility (WIP by dheidler) * Merge libproxy branch (WIP) G3 Better documentation API docs != documentation. Ideas About G3: * We have a mechanism in place to add "guides" and "howtos" to the API docs. If you look at http://www.llvm.org/docs they have an API much bigger than us, and the documentation page list human-written guides explaining how to start, examples, etc. G4 Make it more usable for apps Ideas about G4: * Non root operation? Make it easy for an app to use the functionality as non-root, and acquire root permissions for certain operations. Like PackageKit, but giving access to the full API. * Improve the old KeyRing. It is showing its 5 years. Transitive trust, cleanup API. Default handlers. G5 Misc * Remove some banners from source code. FUNCTION NAME: foo FUNCTION TYPE: bar Cheers Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org