[cldp] Re: libraries wrapping incompatible interfaces

  • From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Sat, 15 Apr 2006 08:23:28 +1000

Karol,

On 4/15/06, Karol Pietrzak <kap4020@xxxxxxx> wrote:
> On Thursday 13 April 2006 20:19, Benjamin Rich wrote:
> > Karol,
> >
> > On 4/14/06, Karol Pietrzak <kap4020@xxxxxxx> wrote:
> > > Hello there.
> > >
> > > The Common Linux Desktop Platform project struck my eye for two reasons:
> > > 1. Because Linux needs this
> > > 2. Because I was working on something vaguely similar
> > >
> > > Quick question, though: would this CLDP contain wrappers for items like
> > > printing, installing menu items, "Autoplay" for CD-ROM/DVD-ROM drives,
> > > etc.?
> >
> > Haven't thought about this aspect yet =P
> >
> > Things like adding menu items is taken care of by freedesktop.org
> > standards and a few apps they've recently released as part of the
> > Portland project, so I think this would be relatively easy to
> > implement on "all ditros".
> >
> > As for printing and filesystem access, I imagined this would be done
> > through the subsystems available in the chosen target desktop manager
> > - eg. GNOME has it's own interfaces into the file system, into cups,
> > etc.
> >
> > The LDBK really applies to desktop apps only, so we'd be dealing with
> > almost exclusively GUI applications - and every GUI app, as we know,
> > makes it's own choices about whether it's a GNOME app, a KDE app, or
> > which toolkit it uses, etc.
>
> One thing I'd like the Linux community to move away from is the strictly GNOME
> or strictly KDE applications.
>
> For example, Gaphor [http://gaphor.sourceforge.net/] is a GNOME UML
> application, while Umbrello [http://uml.sourceforge.net] is a KDE UML
> application.
>
> I think it leads to a lot of duplication, just like the current RPM situation.

I definitely agree, but until a universal toolkit is chosen, I think
this will continue to happen. I don't think the CLDP can do anything
about this - people will continue to cling to their favourites until
the two are totally integrated. Or, until GTK wins out, which I can
only presume will happen eventually because QT is not completely OSS,
and so I think the OS community will eventually dump it.

> > With the BrickLayer idea, an application would be able to require GTK,
> > GNOME, CUPS, Bonobo etc. are present and then implement things it's
> > own way.
> >
> > > These are features that exist right now, but the problem is that
> > > developers can't take advantage of them without selecting a specific
> > > software package, such as CUPS or KDE.
> >
> > This is of course the problem, but until we (eg. the whole Linux
> > community) can universalize all these subsystems, introducing it in
> > CLDP would be a big duplication of effort, in my opinion. We either
> > take sides by saying 'use CUPS for everything, that all this platform
> > supports or recognises' - which in the OSS community, would be
> > political suicide;  or we make our own universal printing subsystem,
> > and add it to the large and ever-growing pile of such systems, meaning
> > that it's success in the platform rides on it's success in everyone in
> > the OSS community liking it and backing it. In short, it's one of
> > those things like a universal calendar format - it's something in the
> > process of being decided, and adding our own version would just
> > confuse things further.
> >
> > Plus, the majority of applications will center around the 'best',
> > simplest and most stable interface (which they already do), and let's
> > face it, that'll probably be CUPS. The platform should simply allow
> > them to do this, and everything will still work.
>
> But something better may supersede CUPS.  In a few years, who knows what may
> come out, and knowing the open source community, it will.
>
> And if we recommend ISVs just access CUPS directly, then immediately thousands
> of applications will not be able to print anymore.  ISVs will just give up on
> Linux because the target is constantly changing.
>
> Case in point: Mac OS X uses CUPS since version 10.2.  If ISVs directly
> accessed CUPS in their applications, Apple would lose the flexibility to
> change printing subsystems, and--even worse--applications would suddenly stop
> working if Apple changed the printing subsystem.
>
> So, Apple has wrapped the CUPS API with their own.  There's only _one_
> printing API for all versions of Mac OS X.
>
> http://developer.apple.com/documentation/Printing/Conceptual/About_MacOSX_Printing/abtprt_chap4/chapter_4_section_2.html
>
> To succeed in the market place, Linux needs the same.  The APIs must be stable
> and exist for many, many years.  I feel API wrappers are needed around the
> following items:
> - printing subsystems: (e.g., CUPS, LPRng, etc.)  we don't want a religious
> war, so we need to support all of them.  the KDE printing subsystem does, for
> example
>
> - menu items: the Portland project should solve some of these problems, but
> when are distributions going to package it?  Since the xdg-* scripts haven't
> been finalized yet and that may take a few more months, I think they will
> start showing up in distributions in six months to a year (depending on the
> distribution's release cycle); I'm sure Debian will take a lot longer.  Of
> course, that doesn't automatically mean that every Linux user will switch to
> the newest version of their distribution.  And what about older
> distributions?  RedHat Enterprise Linux 3 is the standard in many
> corporations.  Should we abandon it just because it's old?
>
> - CD/DVD drives: the most cross-distribution manner of detecting CD/DVD drives
> is by brute-force; try to access /dev/hd* and /dev/sd* and see which is a
> CD/DVD drives.  Perhaps there's a better way nowadays with sysfs.  SuSE, for
> example, has a way to get a list of CD/DVD drives through their API.
>
> I think this list can continue, but those are big issues that can be wrapped
> with a stable API while still promoting development, growth, and different
> perspectives.
>
> But the critical point I want to make is that we NEED an API to wrap these
> things.  The high development, high change environment such as Linux needs
> one in order to attract ISVs.
>
> Thanks for your time!

All extremely valid points, except once again we can't really make a
universal printing or filesystem access layer. There are no doubt
already apps out there trying to achieve this - adding our own would
be a duplicate of effort.

But we might as well choose and sponsor some worthy projects to be our
designated default 'layer' apps for printing etc. - I'll look into
this, post suggestions if you have some project in mind.

-Ben

> --
> Karl Pietrzak
> kap4020@xxxxxxx
>
>
>

Other related posts: