[cldp] Re: libraries wrapping incompatible interfaces
- From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
- To: cldp@xxxxxxxxxxxxx
- Date: Sat, 15 Apr 2006 16:25:02 +1000
Karol,
> > So, I hearby decree that someone can get stuck into writing one of the
> > following, as long as it's not me, at least for the moment while I try
> > and get the LDBK right and perhaps publish 1 single line of code =)
>
> Well, I can be that software guy. I actually already have some code in place
> for the concepts you mention, like the Linux Desktop Printing Layer.
Fantastico!
> > Linux Desktop Printing Layer - integrates with CUPS, allows an
> > application to get a list of installed printers, and the default
> > printer, and then, uh, print to them. The problem here is - do we make
> > our own printer detection and support system, or do we just make an
> > interface to a spooler (in this case cups) so that a program can print
> > to whatever printer the user has already set up through the
> > distribution? I strongly favour option 2, since it won't interfere
> > with the distro specific printing setup, and it also means we won't
> > have to spend 2 years re-inventing the wheel and developing the mother
> > of all printing systems
>
> I agree with you, and I like the name too. :) I'm in favor of interfaces to
> as many spoolers as need be. This will allow preservation of an API while
> still allowing competing spoolers to exist and change (see Mac OS X example).
>
> This is what KPrint does, and technically it shouldn't be that hard.
I think CUPS is probably the most promising, but if we need to support
other spoolers, then certainly I agree we should. I'll leave the way
multiple spoolers are supported up to you, though I think we should
have default printing functions accessing CUPS.
> > Linux Desktop Volume Layer - integrates with HAL/D-Bus to allow an
> > application a list of available removable devices, and their status.
> > As for the 'default' CD or whatever device, I think we should let the
> > application handle this - after all, few people have more than one CD
> > drive, and those who do can wait four seconds for an app to scan both
> > to see which has a disc in it, and/or which has the right disc in it.
> > Strongly recommend we rip of gnome-volume-manager =P
>
> Cool... could you elaborate on gnome-volume-manager or send me to some page?
> I'd like to know more about it before I start writing code.
Here is the udev/hal/dbus/gnome-volume-manager stack of functionality
as I understand it:
udev is a userpspace utility which interfaces with the kernel, and
dynamically provides the /dev tree of device nodes, eg. from the
bios/kernel to userspace apps. it is a replacement for the old static
/dev node tree. it has something to do with sysfs, which is also
implemented by the kernel and provides device information in /sys -
though I don't know if udev provides the info or the kernel does.
hal is the linux 'hardware abstraction layer', which picks up devices
from the system, and allows abstracted access to them. it runs as a
daemon (and is also presumably a set of libraries for abstracted
hardware access)
dbus is a messaging system, which allows applications to send messages
to other applications. it's like corba or dcom. it's used with hal to
inform various applications that such-and-such a device has been
loaded.
gnome-volume-manager (along with a few other volume managers out
there) is a 'policy agent' which sits on top of the udev/hal/dbus
stack, and implements user-specified policies on loaded devices - eg.
'when someone inserts a dvd, start playing it with X dvd move player
program'.
Since it's stable, GTK, and doesn't have any crazy QT/KDE
meta-compiled event-driven thread crap in it, I was thinking it might
be a nice codebase to start from in designing, effectively, a stripped
down version of that very thing. Since looking into it though, it
doesn't seem useful since we don't want to enforce policies on devices
(we don't want to mount anything, we just want access to devices
through hal/dbus).
But gnome-volume-manager contains (or uses, or is hard-coded with,
er...) something called pmount which seems to be a core component.
Maybe this is worth a look?
The whole hal/volume-manager/etc. thing is part of Project Utopia, I
couldn't find the actual authors (other than that Robert Love appears
to written the original). I found this CVS link but I don't know if
it's current or they've moved the current sources to somewhere else:
http://cvs.gnome.org/viewcvs/gnome-volume-manager/
You can get the latest stable source tarball from the gnome site:
http://ftp.gnome.org/pub/GNOME/desktop/2.14/2.14.0/sources/
Take a look, tell me what you find =)
> Along with what you mention, one thing I'd like to enable ISVs to allow easy
> multi-CD installs. The reason this irks me is because even something like
> Unreal Tournament 2004 is not installable by default on most modern Linux
> distributions because it doesn't recognize supermount-type CD/DVD drive
> installations.
I agree, this should be top priority. Although I think the device
layer should allow general access so a program can scan drives - after
all, programs of the future will probably be distributed on thumb
drives (if not in fact, er, over the net).
> > The LDPL (which we can codename Sally for convenience)
> > would not allow a user, or an app, to search for printers or match
> > correct drivers; nor would the LDVL (which we'll call Norwood) ask the
> > user which was their default CD drive, etc.
>
> Sounds good! We'll also have to avoid trampling on distribution makers toes:
> SuSE has its own dialogs for configuring CD/DVD drives, but the beauty of a
> library is that we can wrap that.
Even so, I don't think we shouldn't wrap too much, it makes our
components too reliant on distro-specific things. My original idea for
the CLDP was to make it very general and open, so that distributions
could do their own integration of it with their systems.
> > I might add these ones to the site soon, you've got me thinking now =)
> > Of course, we will need someone to, um, write them - you're more than
> > welcome =P
>
> Gladly. :) Like I said, I already have some code. Here's a few more details
> on this library that I've thought up along the way:
> 1. I also want this library to gain a large user base in both the commercial
> and non-commercial spheres. So, I would like the license to be something
> along the lines of the zlib license, which basically allows anything.
>
> I think this library would be staticly linked for convenience, at least in the
> beginning.
What does the zlib license entail, is it like the berkley license?
Statically linked meaning, developers would compile their apps against
the source of the printing library? I think a more dyanmic model might
work better for making changes to the libraries - we want stable API's
with long release cycles, which can be distributed closed and without
the need for recompilation. I may be misunderstanding you though?
> 2. Great names, IMO! I think aesthetics is very important, even for a purely
> developer-oriented library like this. The names you've given also illustrate
> the different components that this library will consist of.
Yeah I'm wondering whether to name everything individually, LD*L could
become confusing after we add another two or three projects =P
> 3. Another component will be the Desktop Integration component, or some such.
> It will install menu items, register MIME types, and use handlers. Like you
> mentioned, the Portland project will do a lot of the work for us, but only
> for modern distributions. The Autopackage folks have already done a lot of
> this, but even they have expressed interest in extracting the hard work
> they've done in wrapping distributions into an external library for ISVs to
> use. It's not perfect, and hopefully we can help them out by having a
> complete library.
> This library will hopefully support older distributions that are still in
> heavy use, such as older releases Debian and RedHat Enterprise Linux
> releases.
All install/uninstall/execution functionality will be part of
BrickLayer - check out the 'packaging' page on the site, I've updated
the spec a little more re these things.
A component for viewing installed apps, deinstalling them, and a
daemon for detecting appfolder apps and starting an install process
when you click on them or something will be components of bricklayer.
As for abstracting a whole install/uninstall suite for ISV's, what
other functions do you think we might need to abstract for ISV's
concerning app integration? I don't really want to abstract the xdg
tools or anything.
> > I agree with the commercial side of things, since this will be a way
> > ot distribute binary apps only. What sort of thing did you mean,
> > though?
>
> Well, I wanted to see whether we agree on the issue of binary-only, commercial
> applications. I think we see eye-to-eye that commercial, binary applications
> should be given first-class status in whatever specifications, documents, and
> software we write.
I agree - the LDML is based on this. Also, I want to bring in an
implementation of the driver-on-demand idea at a later stage when I
can start writing the LDML (it was another project utopia idea that
unfortunately dried up around the end of 2004).
This platform should be for anyone who wants to create an application
and have it work on 'Linux', doesn't matter if they're commercial -
the more we can entreat commercial companies to port their stuff from
windows to Linux, and under some sort of sane standard instead of
getting a 1st year CS student to write it for them in motif, the
better =)
-Ben
> --
> Karl Pietrzak
> kap4020@xxxxxxx
>
>
>
Other related posts:
