glib in kdesupport: yes or no?

[George Staikos]

On Monday 10 March 2003 00:50, Havoc Pennington wrote:
> On Sun, Mar 09, 2003 at 08:58:14PM -0500, George Staikos wrote:
> >   1) Communication, here in The Internet Age, gets an F.  Most KDE
> > developers have never even heard about DBUS, at least not until this past
> > week.  How do you expect people to accept such things if they are left
> > out of it until the last minute?  These hundreds of developers are being
> > asked to change the foundation of the core of their system to code not
> > written by them, not designed by them.
>
> Keep in mind a couple of things, 1) D-BUS is maybe 30% done if that
> and still open to large changes 2) there were more KDE developers
> initially involved than GNOME developers, quite a few people (a
> dozen-ish I think?).  The whole thing was more or less Matthias
> Ettrich's idea as I understand it, though he hasn't had a lot of time
> to work on it.

    Are you open to a complete redesign of D-BUS if KDE users decide that it 
is not usable in its current form?  The design issue is often more important 
than the implementaion for something like this.  Now that KDE developers have 
access to D-BUS lists and know that it even exists, perhaps we will find time 
to contribute in a more open fashion.

    You have to be very careful about only taking a few developers in a 
non-open fashion for such critical decisions at this point in the life of KDE 
for several reasons.  First and foremost, there are too many developers who 
contribute very large portions of their time to KDE.  It has grown by leaps 
and bounds since 2.0 days even.  If you want to change a critical component 
of KDE one day, you need to get feedback from the project as a whole.  
Second, you cannot rely on a few developers always doing their duty in a 
timely fashion.  We don't get paid to do this, and we can disappear for weeks 
on end.  The points of failure have to be taken into account.

> I've been relying on the KDE developers involved to tell KDE about
> D-BUS, rather than doing it myself; I have my hands full selling it to
> GNOME as some may have noticed if you lurk on our flamewars. ;-) But
> I'd be happy to do a 'briefing' for this list.

   If only I had enough time for the KDE lists alone...

> I'd encourage everyone to get involved and to look at the
> design/implementation. The list archives contain all discussion that's
> occurred and have always been public. Also please feel welcome on
> #dbus on freenode. We'd still be eager to make *any* changes that will
> be desired for KDE adoption, though I admit I'd rather hear about them
> in the next few months than next year, because I do want to start
> using D-BUS in systemwide mode soon (that is my excuse for hacking on
> it).

   As would I.  Please, KDE developers, join the DBUS discussion and 
development cycle.  I just don't have time to contribute much personally, 
other than the occasional comment.  I know some of you will have much more 
feedback about this though.

> An important question for KDE is, *if* you were going to use it in
> addition to or instead of or as a backend for DCOP, how would that
> migration work, and how would the code be set up.  e.g. would you a)
> swap out the DCOP backend, replacing libICE; b) introduce a new API
> enough like DCOP to be easy to port to, but different from DCOP; c)
> keep both DCOP and D-BUS as separate things; or d) some combination of
> those or something else. We can design D-BUS to make each of these
> paths easier or harder.

   I spoke with a few KDE developers about this too.  I suspect we will have 
to make a bridge between DCOP and D-BUS, keeping DCOP around for backward 
compatibility.  If D-BUS lives up to expectations, hopefully it would become 
the new internal API and mechanism for KDE with DCOP apps being bridged over.  
Having two separate, unintegrated RPC mechanisms is a bit silly.  This is 
IMHO of course.  We have to make sure that D-BUS is at least as easy to use 
for the developer as DCOP is.  That means the API must easily support calls 
and signals the way we have them now.  Some of this will be our own 
responsibility of course.

> My hope is that D-BUS will turn out nice enough technically that
> people will really want to use it.

   As do I.  I don't however believe in change for the sake of change.  It 
really needs to provide tangible benefit to KDE.  One thing we really could 
use is better secure, remote support.  DCOP is rather lacking in that area 
right now.  Unfortunately DCOP is really not network enabled the way the rest 
of KDE is.

> >    1b) This "system" is a system developed by hundreds of individuals,
> > 99% in their spare time to suit their own purposes.  There is no
> > governing body, no pay-cheque.  No-one can impose changes or regulations
> > on these people.  Even if you try, these people will surely revolt and
> > relocate [fork] the project. This is no small proposal.
>
> But the nice part is that I'm not proposing one huge thing. All I'm
> doing is presenting a case for a particular goal (interoperability),
> and pointing out that this can be achieved via a lot of small,
> independently valuable efforts. If we solve the menu system but not
> MIME types, menu system work is still valuable. If we do D-BUS but
> can't figure out DND types, D-BUS is still valuable.

   They all add up to a big change in direction, and I think in many cases the 
real benefits of one change are not realised until other changes are also 
made.

> I think the answer there is just to start using pkg-config to detect a
> dependency at the same time that you're adding the dependency (or
> bumping the version of the dependency you require) for some other
> reason anyway. For example if you suddenly require libxml version
> X.Y.Z and it happens to include a .pc file, suddenly it's no extra
> burden to require the version with the .pc file.
>
> Similarly pkg-config was introduced with GTK 2, when apps had to
> require a newer GTK anyhow.

   That is probably the best approach.   More dependencies still do hurt 
though.  From what we've seen over the past week, we may not have a choice 
about pkg-config anyways.  (regarding glib, on the other hand, I believe we 
still have an easy choice there)

> >    3) Control.  When the desktop begins to rely on external libraries,
> > the developers start to lose control over the system.  We have severe
> > problems with this already.  Example: OpenSSL - breaks binary
> > compatibility every second release, and source compatibility regularly as
> > well.  We are at the whim of the people controlling the common elements. 
> > Conversely, we don't want everyone who uses the libraries with their
> > fingers all over it.  Quite frankly I've seen more bad code than I have
> > good code.  (I am guilty of some of that bad code too, of course.) 
> > Exactly how is this supposed to be administrated, especially considering
> > that KDE - arguably the largest user of this technology if adopted - has
> > no real budget or steady developers.  Even if
>
> GNOME of course has the same issue. FWIW, I think GNOME and KDE both
> have much higher standards and stricter policies than most projects.
> We simply take the union of those policies, pick the strictest rules
> where there's overlap, and use that policy.
>
> There's certainly a level of trust required here, but it doesn't seem
> impossible to achieve.

   I think it might be more difficult than you think.  I will be surprised if 
there are many libraries at all that both projects agree upon, for instance.  
Perhaps libxml (already), pkg-config (for KDE 3.2).  We almost always make 
external libraries optional anyways.  This is what I am requesting for glib 
also.  I don't see why glib should be required because a KDE required 
component has decided to require it, while other KDE components have gone to 
great lengths to make their components optional.  What would happen with the 
"freedesktop" packages?  Would they become required components to build 
KDE/Gnome/other desktop?  Once there is a required component like this, I 
think KDE needs serious control of the direction it heads in.  Of course, so 
do the other desktops.  I think it is for this reason that KDE will never 
share a "VFS" with any other desktop unless the other desktop adopts KIO.

> >    4) Containment.  One of the most annoying things about installing
> > software is having to search all over for dependent packages. 
>
> GNOME had a large discussion about this before moving to our current
> many-small-packages setup. Basically it turned out to be a non-issue
> because we have tools (jhbuild, garnome) that automate everything. So
> it's easier now with all the small packages than it was before with 10
> or so compiled manually.
>
> However, I don't want to rely on convincing anyone of that, so a
> freedesktop.tar.gz is totally fine with me. In fact I made a
> gtk-and-all-dependencies tarball once, and did some pkg-config work to
> support it (so you can build the whole tarball without installing any
> of it).

   I definitely prefer this.  Especially from a developer point of view, but 
also as a user.

> >    5) Wrappers.  In the end, someone will be using wrappers.  I object to
> > having to obsolete existing and working C++ code to use C code simply
> > because that's the lowest common denominator.  KDE is fundamentally a C++
> > desktop and as such we want to use the power of C++.  Compiling C code
> > with a C++ compiler just gives us the inefficiencies of the C++ compiler
> > of the day, with the loss of power that was available.  Are the other
> > desktops prepared to accept C++ as a core requirement, and use C wrappers
> > to the C++ code?  Or is KDE to be the one to bear the burden of wrapping
> > C code with C++ to fit the development model?  Will we even have to use
> > C# backend code at some point?
>
> IMO the shared implementation that's needed is small enough that this
> isn't a huge issue. It's only a big problem for a couple things
> (notably vfs). But, fwiw, GNOME would probably be willing to depend on
> C++ (already does really),

    I think this remains to be seen.  We need to see some components mature.  
I don't know of too many projects that end up with less code and fewer 
interfaces than originally predicted.

> and no, I don't think we could add C#.

    Phew :)  

> >    Standardization and sharing technology are noble goals indeed.  I
> > do infact support this.  I do not support the means to this end
> > right now.  I need answers, procedure and compromise, and I think
> > the rest of the desktop developers need this as well; KDE, Gnome,
> > XPDE, and more.
>
> It's a matter of small steps. We don't have to decide on huge
> intractable goals - doing each individual thing, as we have interested
> developers or opportunities, will move us in the right direction.
> Discussing the big picture is still valuable of course.

  I think discussing the big picture is critical.  Complex projects need to 
have a focus and a goal, even if it is far ahead in the future and done in 
baby steps.  Taking many baby steps blindly (with no direction) is perhaps a 
scary situation in that there is no idea of where we will end up.  We need to 
know why we are taking these steps in the big picture of things.  If there is 
no big picture, there are probably better places we can spend our effort.  
That would certainly not help your goals of choice vs fragmentation.

> D-BUS is pretty much opportunistic for example; we had two developers
> (myself and Anders) that found an excuse to spend paid work time on
> it, so we are taking advantage of that and trying to get it done while
> we can. If we can't get broad acceptance, fine, we both needed to
> write it for work reasons anyway - but if it's more broadly useful,
> that will be awesome. May as well take advantage of the work.

    Of course!  Great example!  The learning experience is worth the work 
alone.

-- 

George Staikos