Re: ORBit 2.3.94
- From: Michael Meeks <michael ximian com>
- To: Sander Vesik <Sander Vesik Sun COM>
- Cc: <orbit-list gnome org>, <gnome-2-0-list gnome org>
- Subject: Re: ORBit 2.3.94
- Date: Sat, 25 Aug 2001 12:16:28 -0400 (EDT)
Hi Sander,
On Sat, 25 Aug 2001, Sander Vesik wrote:
> Unfortunately, the announcement is missing several things like a a big
> bold lettered (and in red) banner readying "We broke API compat with
> older linc!"
This does not concern me; and I respectfuly suggest that you might
more profitably use your considerable time and undoubted powers of
constructive criticism on the bottom of the API stack - which as it seems
to me is still not frozen, nor are packages released enabling people to
build them easily.
Incidentaly and peripherally there are good technical reasons for
the API changes:
a) work round a Linux kernel 'poll' bug
b) make the thing build on Solaris.
Which are non-negotiable 2.0 features, both _requiring_ API
breakage [1].
> If linc is to continue undergoing large changes for orbit (and nothing
> else verifiably uses it) it should be made a private library inside
> ORBit2 with no published API. Ortherwise it should be treated as if it
> was api frozen. I mean - really api frozen.
There is as far as I can see precicely 0 point in freezing APIs
that are built on top of non-frozen APIs. The day I have a 'really api
frozen' platform under me - I will consider the API harder frozen. It
seems to me that keeping 100% binary and source compatibility for all
applications using either (linc + ORBit2) set seems like an extremely
attractive compromise for now.
Your suggestion for moving linc into ORBit has some merit - but
since it's API is an integral part of the ORBit2 API - pwrt. connection
breaking it would not actualy help in this situation. Either way I'm
hoping we will have an ABI tagging tool soon to mark the linc interfaces
as unstable so I can continue with my job without undue heartache.
Warmly,
Michael.
[1] - and indeed to fix the (less critical, but theoretical) 'server' side
of the Linux kernel workaround, it's possible the API will need
re-reworking again at some stage.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]