| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Just to bring some new better terms: |
| 5 |
- - backend: is the whole thing which has to be written |
| 6 |
- - provider: the part between backend and package manager |
| 7 |
|
| 8 |
Luis Francisco Araujo schrieb: |
| 9 |
> René 'Necoro' Neumann wrote: |
| 10 |
>> While thinking about it, I wondered, why we have so many different |
| 11 |
>> portage frontends - and each having its own portage backend. As there |
| 12 |
>> are different approaches in defining a GUI, there is only one approach |
| 13 |
>> of getting your information from portage. So instead of having one GUI, |
| 14 |
> |
| 15 |
> It might theoretically sound like that , but different GUI approaches |
| 16 |
> might bring different backend approaches too. |
| 17 |
|
| 18 |
Ok - I only thought about the object oriented approach. That is true. |
| 19 |
> |
| 20 |
>> I want to have one backend, which can be used by all different GUIs. |
| 21 |
>> This makes the development of new GUIs simple - and might even be useful |
| 22 |
>> for small scripts. |
| 23 |
> |
| 24 |
>> Also this backend should it make possible to access different package |
| 25 |
>> managers (portage, paludis, pkgcore, equo) through one standardized API. |
| 26 |
>> Thus in the end all GUIs will support all different Gentoo Package Manglers. |
| 27 |
> |
| 28 |
> |
| 29 |
> It really sounds nice, i suppose it'd be a matter of defining what would |
| 30 |
> be the exact scope of this back-end. I don't think it might offer all |
| 31 |
> the necessary stuff for different package managers to make truly |
| 32 |
> independent a GUI from back-end code , nevertheless , it could really |
| 33 |
> offer a set of sharable standard procedures (probably as a library?). |
| 34 |
|
| 35 |
Hmm ... this has to be defined. I don't know in detail what are the |
| 36 |
differences between the package managers. But I think all of them extend |
| 37 |
portage in a way. So one could agree on defining portage as the basic |
| 38 |
set of operations supported - and everything else has to be implemented |
| 39 |
by the GUI itself. |
| 40 |
|
| 41 |
> |
| 42 |
>> HOW? |
| 43 |
>> ==== |
| 44 |
> |
| 45 |
>> Basically I want to have one service in the middle, that is accessed via |
| 46 |
>> DBus. This service itself calls pkg-manager backends which in turn get |
| 47 |
>> information out of the pkg manager. |
| 48 |
> |
| 49 |
>> For the second part there are two different approaches: |
| 50 |
>> 1) Have all backends in the service itself. |
| 51 |
> |
| 52 |
> This would be pretty much like a library, there is no need for DBus in |
| 53 |
> such a case i think. |
| 54 |
|
| 55 |
The library still has the problem that you have to find a common |
| 56 |
demoninator as the language to write the library in... (And it produces |
| 57 |
some overhead, as you have to access portage using C for example). |
| 58 |
|
| 59 |
Ok ... you could write e.g. the portage provider in Python and put a |
| 60 |
small C layer on top to have the normal bindings... |
| 61 |
|
| 62 |
>> 2) |
| 63 |
>> - P: Different languages can be chosen - and it is easy to add a new |
| 64 |
>> backend. |
| 65 |
> |
| 66 |
> This makes a more proper usage of DBus i suppose ; |
| 67 |
I would still prefer this way - if Dbus hadn't some open issues like |
| 68 |
authentication |
| 69 |
|
| 70 |
> nevertheless here we |
| 71 |
> could face the problem of DBus not getting or handling languages |
| 72 |
> features the programmer would like to take advantage of |
| 73 |
You and your Haskell ;P --- but you are true: DBus is object oriented |
| 74 |
|
| 75 |
> this also would involve creating different sub-sets of API for each language to |
| 76 |
> circumvent some of these issues ... and the thing might get more complex.... |
| 77 |
no - there would be still be one single API ... the GUI itself then had |
| 78 |
to map it to get the way it wants it to be |
| 79 |
|
| 80 |
|
| 81 |
>> - P: The backend might be provided by the package manager itself, which |
| 82 |
>> makes it easier to maintain. |
| 83 |
> |
| 84 |
> The package manager or the GUI front-end?, if its the former, we would |
| 85 |
> have to talk the different package managers developers into this , and |
| 86 |
> if it is the later, .... it's pretty much what all the GUI front-ends |
| 87 |
> are already doing i guess. |
| 88 |
|
| 89 |
I meant the "backend providers" for the service to be maintained by the |
| 90 |
normal package managers. |
| 91 |
|
| 92 |
Regards, |
| 93 |
- - Nec |
| 94 |
|
| 95 |
-----BEGIN PGP SIGNATURE----- |
| 96 |
Version: GnuPG v1.4.7 (GNU/Linux) |
| 97 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
| 98 |
|
| 99 |
iD8DBQFG80UK4UOg/zhYFuARAs/RAJ4zoVQv2CwAmVKnKATej/+7CiS7tgCeOHRO |
| 100 |
R5qeYPqLctN3UQFuaL9TeGM= |
| 101 |
=08iL |
| 102 |
-----END PGP SIGNATURE----- |
| 103 |
-- |
| 104 |
gentoo-guis@g.o mailing list |
Archives