Technicall issues

[Chema Celorio <chema celorio com>]

[For the KDE guys, don't forget to CC: the setup-tool-hackers
list]

This is great, it seems like we are getting somewhere.

Now, lets show everyone how good we can get along, not 
just talk about it :-).

This helps KDE and GNOME because we are not just saying that
we can live together with KDE, we are actually SHOWING it,
which is a much better thing to do than talk. Linux progress
on the desktop is beeing halted by users and the industry
waiting to see who will win GNOME or KDE. This is very very
very bad for us, because this is just stoping us to move forward.
Now, if we _SHOW_ the world that KDE and GNOME can live together
fine, people will start making desitions. Maybe the choose KDE
maybe the choose GNOME but they will choose something and start
developing for Linux on the desktop, because they will not be
afraid of choosing any of the two desktops, if they choose the
"loosing" one, they will still be able to use their programs
nicelly on the other desktop. They will get no huge disadvantages.

It seems like we are going to reach a consensus, so I want to
start moving into the technical details. Here are my _sugestions_
for how i would technically would do it if things where the
other way arround. If you are unsure what a "sugestion" means
go look it up in the dictionary [we have a nice GNOME applet
that will help called gdict-applet ;-)]

1. Focus on the front-ends for now, the task is large enough
by itself.

2. Spend more coding-time writing the common code (the equiv of
our src/common).

3. Write only one or two front ends for now. I suggest using the
users and the boot tool because the XML structure is more stable
than the other ones. The other ones are not unstable per see, but
this ones are very stable and should not change.

4. don't spend time polishing the user interface/making it feels
right. That is easy to do once everything else is working fine.

5. Make a clear separation in the code that _gets_ the XML and
the code that _parses_ the XML. We have found a problem in the
current way of doing things so we are going to have to change
the way we talk to the backend, the XML will be the same but
the conversation will be a little different. I can go into
more detail if you guys want on the chagnes. The main idea
is that the backend is invoked like a GET and a POST http request.
On the simple case we will invoke the backend like :

[chema@suzzy backends]$ ./network-conf
/get config
<xml>
  <the backend spits the xml, the current --get operation<
</xml>
/set config
<xml>
  <the backend gets the xml from the FE, the current --set operation
</xml>
/end
[chema@suzzy backends]$ 
..

6. Have a working copy of the XST tools for GNOME running. Yes,
this means that you need bleeding edge libraries for GNOME, but
it might help you. IMAGINE GNOME bleeding edge code taking over
your CPU !!! What a scary feeling ..;-)/

Oh one more thing, there are some backends that you should look 
more than others, the coding style is different (a lot better).
We are cleaning the rest of the backends gradually. If you want to
get familiar with the backends i sugest reading :
network, shares, users & boot.

regards
Chema

P.S. : NEtscape didn't trashed my email this time !! weeeee !