Gentoo Archives: gentoo-guis

From: "René 'Necoro' Neumann" <lists@××××××.eu>
To: gentoo-guis@l.g.o
Subject: Re: [gentoo-guis] One backend for alle portage GUIs
Date: Fri, 21 Sep 2007 04:25:08
In Reply to: Re: [gentoo-guis] One backend for alle portage GUIs by Luis Francisco Araujo
Hash: SHA1

Just to bring some new better terms:
- - backend: is the whole thing which has to be written
- - provider: the part between backend and package manager

Luis Francisco Araujo schrieb:
> René 'Necoro' Neumann wrote: >> While thinking about it, I wondered, why we have so many different >> portage frontends - and each having its own portage backend. As there >> are different approaches in defining a GUI, there is only one approach >> of getting your information from portage. So instead of having one GUI, > > It might theoretically sound like that , but different GUI approaches > might bring different backend approaches too.
Ok - I only thought about the object oriented approach. That is true.
> >> I want to have one backend, which can be used by all different GUIs. >> This makes the development of new GUIs simple - and might even be useful >> for small scripts. > >> Also this backend should it make possible to access different package >> managers (portage, paludis, pkgcore, equo) through one standardized API. >> Thus in the end all GUIs will support all different Gentoo Package Manglers. > > > It really sounds nice, i suppose it'd be a matter of defining what would > be the exact scope of this back-end. I don't think it might offer all > the necessary stuff for different package managers to make truly > independent a GUI from back-end code , nevertheless , it could really > offer a set of sharable standard procedures (probably as a library?).
Hmm ... this has to be defined. I don't know in detail what are the differences between the package managers. But I think all of them extend portage in a way. So one could agree on defining portage as the basic set of operations supported - and everything else has to be implemented by the GUI itself.
> >> HOW? >> ==== > >> Basically I want to have one service in the middle, that is accessed via >> DBus. This service itself calls pkg-manager backends which in turn get >> information out of the pkg manager. > >> For the second part there are two different approaches: >> 1) Have all backends in the service itself. > > This would be pretty much like a library, there is no need for DBus in > such a case i think.
The library still has the problem that you have to find a common demoninator as the language to write the library in... (And it produces some overhead, as you have to access portage using C for example). Ok ... you could write e.g. the portage provider in Python and put a small C layer on top to have the normal bindings...
>> 2) >> - P: Different languages can be chosen - and it is easy to add a new >> backend. > > This makes a more proper usage of DBus i suppose ;
I would still prefer this way - if Dbus hadn't some open issues like authentication
> nevertheless here we > could face the problem of DBus not getting or handling languages > features the programmer would like to take advantage of
You and your Haskell ;P --- but you are true: DBus is object oriented
> this also would involve creating different sub-sets of API for each language to > circumvent some of these issues ... and the thing might get more complex....
no - there would be still be one single API ... the GUI itself then had to map it to get the way it wants it to be
>> - P: The backend might be provided by the package manager itself, which >> makes it easier to maintain. > > The package manager or the GUI front-end?, if its the former, we would > have to talk the different package managers developers into this , and > if it is the later, .... it's pretty much what all the GUI front-ends > are already doing i guess.
I meant the "backend providers" for the service to be maintained by the normal package managers. Regards, - - Nec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - iD8DBQFG80UK4UOg/zhYFuARAs/RAJ4zoVQv2CwAmVKnKATej/+7CiS7tgCeOHRO R5qeYPqLctN3UQFuaL9TeGM= =08iL -----END PGP SIGNATURE----- -- gentoo-guis@g.o mailing list