-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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?).
> 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.
> 2) Have the backends extra - and they are called by DBus itself.
> Pros & Cons:
> - C: All backends should be written in the same language, what could be
> difficult, as different pkg-managers use different languages.
Indeed, as i mentioned before, there might exist some dependencies in
the way objects are handled between a GUI and a back-end (Controller),
and its programming language.
> - P: Faster?
I think so.
> - P: Different languages can be chosen - and it is easy to add a new
This makes a more proper usage of DBus i suppose ; nevertheless here we
could face the problem of DBus not getting or handling languages
features the programmer would like to take advantage of; 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....
> - 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.
> - C: More overhead.
> Open Issues
> - How could we send complex objects with dbus?
> So guys ... now the question: Could you imagine to put efforts together
> and plan such a thing? =)
I don't think it could exist something like 'one back-end to rule them
all', and i barely see the advantage of using something like DBus, but
it could exist some kind of library offering sharable procedures for
different packages managers , and from there on, each GUI package
manager could use whatever fits best its design and model. So, as i
said, it is probably a matter of defining a scope for this idea.
Thanks and Regards,
Luis F. Araujo "araujo at gentoo.org"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)
-----END PGP SIGNATURE-----
email@example.com mailing list