Re: Next stop Utopia, full steam ahead?

[David Zeuthen <david fubar dk>]

On Mon, 2004-06-07 at 23:22, Joe Shaw wrote:
> On Mon, 2004-06-07 at 23:12 +0200, David Zeuthen wrote:
> > If it only means creating and maintaining a 'stable' branch of HAL for
> > the duration of the GNOME 2.8 series, sure, no problem, I can commit to
> > that. 
> 
> I'm not so sure that an API/ABI guarantee even within a stable series is
> a good idea quite yet.  For example, at this point I'm still not sure
> that "net.ethernet.80211" is right instead of "net.ethernet.wireless" or
> "net.wireless".  Unfortunately we have a string API and with it are all
> the problems of a string API.  It's not the libhal API I'm concerned
> about... that I think we can make relatively stable, it's the naming and
> existence of most of the properties.

Oh, I was in fact thinking about the string API; libhal or the D-BUS
network API hasn't changed much at all. I think that for at least
storage devices we have a pretty solid API; at least it works well
today, so freezing it in a stable branch should be OK. My understanding
is that we only would need to maintain this branch for 2.8, we can make
another stable branch for 2.10.

(and in fact stable HAL releases shouldn't necessarily follow stable
GNOME release, that might change if other desktops become interested,
but that is a bit premature :-)

> > The only interesting things we could export in that stable branch
> > at that point though would be storage and network devices and maybe USB
> > printers (Joe?), these seem to be pretty stable and useful today. 
> 
> I wouldn't want to limit the devices that are exposed...

No, me neither, but we would only support certain devices, e.g. storage
and networking. Everything else would still be there, but unsupported.

> > But the apps and libraries would still need #ifdef stuff whether to use
> > HAL or not since Linux 2.6+udev+HAL might not be available everywhere
> > where GNOME runs. The benefit IMHO would offset this cost though, but I
> > guess I'm biased. Now, whether modules in the desktop have time to
> > properly integrate with HAL for GNOME 2.8 is another discussion ;-)
> 
> Yeah.  As far as gnome-vfs integration goes, the API should be totally
> encapsulated so we don't have to worry about leakages into the public
> API.  I'd make the --enable-hal configure flag default to off so that it
> has to be explicitly enabled.  From a programmer's standpoint there's no
> difference, but the volume manager would have different behavior.
> 

Yeah, true. Well, first off all the gnome-vfs patch would have to be
finished (I just posted the second version today), reviewed and
integrated into CVS :-)

> As for other apps, a policy of use-at-your-own-risk a la eel seems to
> make more sense.
> 

Yeah.

Cheers,
David