-----BEGIN PGP SIGNED MESSAGE-----
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 - http://enigmail.mozdev.org

iD8DBQFG80UK4UOg/zhYFuARAs/RAJ4zoVQv2CwAmVKnKATej/+7CiS7tgCeOHRO
R5qeYPqLctN3UQFuaL9TeGM=
=08iL
-----END PGP SIGNATURE-----
-- 
gentoo-guis@g.o mailing list