Re: new module: eggcups

[Havoc Pennington <hp redhat com>]

Hi,

On Sat, 2004-07-17 at 07:49, Jody Goldberg wrote:
> 
> This is going to be a sticking point.  While the d-bus support is
> definitely nice, I don't see us being able to depend on it's
> existence in GNOME proper.  On the corporate level we can all
> attempt to ship with the patch, but wearing my community hat I don't
> see us requiring it even when it merges into cupsd.  IMO we can't
> force a user to upgrade some piece of infrastructure to work.

The key thing is that it's not required to build and install GNOME, or
to use GNOME as a desktop shell. It's just required to use GNOME as a
deeply integrated OS component that's aware of hardware, etc.
So it's natural that deep OS integration will require some OS changes.

Moreover not all operating systems by any means use CUPS, so we're
*already* heavily relying on how the OS is implemented.

> We could potentially supply a fallback gnomeprintd which consists of
> the cupsd d-bus patch and some polling of cupsd.  It's a brutal
> hack, but would likely provide a decent fallback.

To me the burden to implement this mess is on someone who cares about
this particular feature working on old OS versions. My view is, if you
want an OS that's set up properly to support a fully integrated desktop,
use a recent OS version with the necessary features.

We often use OS-specific features, such as reading uid/gid off of a unix
domain socket. This one isn't even like that, because you can install a
different cupsd (while replacing the C library or kernel isn't typically
feasible). Again many systems don't even include CUPS.

Let's face reality: an XP/OSX competitive desktop will require a lot of
assumptions about the underlying OS, from use of CUPS to HAL to whatever
else. We want to keep GNOME working as a desktop environment without all
that, but to provide the full desktop user experience including handling
all the hardware we need to assume an OS that supports this stuff.

Why should we force all the "full fledged desktop OS" integration
patches to be in distribution-specific patches? That just makes work,
and puts distributions such as Debian at a disadvantage because they
have to go copy the patches out of the Red Hat and Novell spec files
instead of simply grabbing mainline GNOME.

Another concern is someone building GNOME from source on an OS that has
the feature, e.g. FC3 will have the CUPS patch, so why shouldn't a
source build of GNOME support the printing feature?

It's also better to have the D-BUS dependent code in upstream because we
need to be showing OS developers *how* to port GNOME to be good on their
OS. If you can look at the GNOME source and say "OK, I need to add this
feature to my OS so it can be used" that's better than having to go look
at Red Hat spec files and copy a bunch of patches out of there to have
full functionality.

Again I'd draw the line as: GNOME should work in its "window manager on
steroids" capacity on any reasonable UNIX/Linux, but I don't think full
desktop OS capabilities are expected on an OS that doesn't really
support them. A working desktop system requires a lot more than just
GNOME.

Let me put it this way - virtually the entire Red Hat desktop team is
currently hacking stuff that we would consider "core OS" rather than the
GUI. That's because the current limitations in the core OS are the main
user-visible problems. We can keep this all Red Hat specific, but I
think the GNOME aspects should be upstream so other people can use them.
If nothing else it will help keep Red Hat, Novell, Debian, JDS, and
other major distributions from diverging in how they implement things.

Havoc