[cldp] Re: libraries wrapping incompatible interfaces

  • From: Karol Pietrzak <kap4020@xxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Fri, 14 Apr 2006 10:42:47 -0400

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.

> 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!

-- 
Karl Pietrzak
kap4020@xxxxxxx

Other related posts: