1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
René 'Necoro' Neumann wrote: |
5 |
> While thinking about it, I wondered, why we have so many different |
6 |
> portage frontends - and each having its own portage backend. As there |
7 |
> are different approaches in defining a GUI, there is only one approach |
8 |
> of getting your information from portage. So instead of having one GUI, |
9 |
|
10 |
It might theoretically sound like that , but different GUI approaches |
11 |
might bring different backend approaches too. |
12 |
|
13 |
> I want to have one backend, which can be used by all different GUIs. |
14 |
> This makes the development of new GUIs simple - and might even be useful |
15 |
> for small scripts. |
16 |
> |
17 |
> Also this backend should it make possible to access different package |
18 |
> managers (portage, paludis, pkgcore, equo) through one standardized API. |
19 |
> Thus in the end all GUIs will support all different Gentoo Package Manglers. |
20 |
> |
21 |
|
22 |
It really sounds nice, i suppose it'd be a matter of defining what would |
23 |
be the exact scope of this back-end. I don't think it might offer all |
24 |
the necessary stuff for different package managers to make truly |
25 |
independent a GUI from back-end code , nevertheless , it could really |
26 |
offer a set of sharable standard procedures (probably as a library?). |
27 |
|
28 |
> HOW? |
29 |
> ==== |
30 |
> |
31 |
> Basically I want to have one service in the middle, that is accessed via |
32 |
> DBus. This service itself calls pkg-manager backends which in turn get |
33 |
> information out of the pkg manager. |
34 |
> |
35 |
> For the second part there are two different approaches: |
36 |
> 1) Have all backends in the service itself. |
37 |
|
38 |
This would be pretty much like a library, there is no need for DBus in |
39 |
such a case i think. |
40 |
|
41 |
> 2) Have the backends extra - and they are called by DBus itself. |
42 |
> |
43 |
> Pros & Cons: |
44 |
> 1) |
45 |
> - C: All backends should be written in the same language, what could be |
46 |
> difficult, as different pkg-managers use different languages. |
47 |
|
48 |
Indeed, as i mentioned before, there might exist some dependencies in |
49 |
the way objects are handled between a GUI and a back-end (Controller), |
50 |
and its programming language. |
51 |
|
52 |
> - P: Faster? |
53 |
> |
54 |
I think so. |
55 |
|
56 |
> 2) |
57 |
> - P: Different languages can be chosen - and it is easy to add a new |
58 |
> backend. |
59 |
|
60 |
This makes a more proper usage of DBus i suppose ; nevertheless here we |
61 |
could face the problem of DBus not getting or handling languages |
62 |
features the programmer would like to take advantage of; this also would |
63 |
involve creating different sub-sets of API for each language to |
64 |
circumvent some of these issues ... and the thing might get more complex.... |
65 |
|
66 |
> - P: The backend might be provided by the package manager itself, which |
67 |
> makes it easier to maintain. |
68 |
|
69 |
The package manager or the GUI front-end?, if its the former, we would |
70 |
have to talk the different package managers developers into this , and |
71 |
if it is the later, .... it's pretty much what all the GUI front-ends |
72 |
are already doing i guess. |
73 |
|
74 |
> - C: More overhead. |
75 |
> |
76 |
> Open Issues |
77 |
> =========== |
78 |
> |
79 |
> - How could we send complex objects with dbus? |
80 |
> |
81 |
> |
82 |
> So guys ... now the question: Could you imagine to put efforts together |
83 |
> and plan such a thing? =) |
84 |
|
85 |
I don't think it could exist something like 'one back-end to rule them |
86 |
all', and i barely see the advantage of using something like DBus, but |
87 |
it could exist some kind of library offering sharable procedures for |
88 |
different packages managers , and from there on, each GUI package |
89 |
manager could use whatever fits best its design and model. So, as i |
90 |
said, it is probably a matter of defining a scope for this idea. |
91 |
|
92 |
Thanks and Regards, |
93 |
|
94 |
- -- |
95 |
|
96 |
Luis F. Araujo "araujo at gentoo.org" |
97 |
Gentoo Linux |
98 |
|
99 |
-----BEGIN PGP SIGNATURE----- |
100 |
Version: GnuPG v2.0.6 (GNU/Linux) |
101 |
|
102 |
iD8DBQFG8vO5BCmRZan6aegRAoa9AJ45D5HyGXSghtJYZohxk/XNhdEr1QCghpgD |
103 |
RlLT3SRt/LZqrVTSmclJjMI= |
104 |
=xUQe |
105 |
-----END PGP SIGNATURE----- |
106 |
-- |
107 |
gentoo-guis@g.o mailing list |