[dcontrol] Names, code, work

[Fabricio Cannini]

 --- Paranoid <paranoid@pcwereld.be> escreveu: 
> > CFG looks much like what i was thinking, 
> > but with more layers.
> > 
> > Layer 1:
> > High-level GUI (QT, GTK, HTML, etc) 
> > that will do the eye-candy stuff.
> > 
> > Layer 2:
> > Mid-level componentized python scripts,
> > will be used by the GUI to handle the config
> files.
> > 
> > Layer 3:
> > Low-level raw config files.
> > 
> 
> I was more thinking about something like this (maybe
> it's the same as
> yours, just clarifying then):
> 
> 1: general gui abstraction library (layer 0 would be
> gtk/...)
> 2: core, uses one protocol to communicate with layer
> 1
> 3: config file parser
> 
> So the only thing that would need te be written when
> porting to another
> interface/gui is layer 1, and this only needs to be
> written once since
> it's common to everything we write (given a specific
> interface).


Yes, it somehow gets to the same place.
I was thiking about the following to the QT port:

1- Strip out KDE's Kcontrol;
2- Pick the config modules that interest to us;
3- Write the one's that we need as KControl plugins;
( That's why i love KParts ;-) 

There's a set of libraries called sig++, 
which were develop as bindings between python and C++
code,
so it can save the day (i'm seriously thinking in
writng the gui's in python, as D3C is not a
performance-savvy app.
 

> > I've mentioned python (even thought i love Perl)
> > because it is not a small project, 
> > that must be very well organized (OO coded) 
> > to grow with minimal pain, and python seems the
> > language that best fits our needs.
> > 
> > I want to hear from you creatures, 
> > what do you think about these ideas??
> 
> I was toying with python,lex & yacc. Someone did the
> work to port
> lexing/parsing to python, maybe we should take
> advantage of this, since
> writing parsers using only regexps+python/perl isn't
> my favorite
> timespending...
> 
> I'm not a big fan of CFG, but their parsers could be
> reused i think.
> The problem i had with them was the usage of XML.
> (which imho is just a
> little bloat to represent a tree of data).
> 
> They switched to WBEM recently (XML not being
> supported anymore). I
> don't know much about the WBEM protocol, but i get
> the impression it's
> quite large/extensive (which doesn't mean it's bad).
> It's network
> transparant though. afaik a wbem-lib for python
> doesn't exist.
> 
> So that leaves us with these options:
> a) Cut the WBEM piece out, and use whatever is below
> it (parsers in perl
> probably)


No way.


> b) Use python lexing/parsing and define our own
> interface. (python has
> CORBA/RPC like features afaik, so these things could
> be network
> transparent without much code) 


Both GTK/GNOME and QT/KDE are CORBA/RPC capable 
(KDE uses DCOP, which is a superset of CORBA), 
so it won't be our worst problem.

BUT, excuse the pun, but this is a HUGE but,
network transparency shouldn't be a priority.


> c) Write a WBEM library for python/whatever we're
> going to use and
> include the WBEM layer from CFG
> d) something else... :p 


In a moment of despair, we could use XML/RPC!! ;-)


> For GUI abstraction: what about extending debconf,
> or just write
> something ourselves?


Really no. Debconf misses many features, 
has an awkward design, and is written in perl.
That's why QT Designer && Glade were made.

Best to you.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com