-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?).

> 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.

> 2) Have the backends extra - and they are called by DBus itself.
> 
> Pros & Cons:
> 1)
> - 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.

> 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 ; 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"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.6 (GNU/Linux)

iD8DBQFG8vO5BCmRZan6aegRAoa9AJ45D5HyGXSghtJYZohxk/XNhdEr1QCghpgD
RlLT3SRt/LZqrVTSmclJjMI=
=xUQe
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list