Re: Spec Status report
On Fri, 30 Oct 1998, Stuart Anderson wrote:
> Due to the prolonged illness and subsequent death of my father-in-law, I
> haven't gotten much accomplished in the past couple of months. Things are
> now returning to normal.
Sorry to hear about this. A death in the family is always difficult. My
sincerest condolences...
> I am currently working on extracting various lists from the DB I have. These
> are available under /spec on the website. There will be more (and more
> complete) lists showing up soon. As always, I'll keep updating things under
> /spec as I make additions. There is now a date on the page so you can tell
> when the document is updated.
Dated materials are a Very Good Thing(tm).
> I spoke with someone from The Portland Group while at ALS. They provide
> compilers, and seemed interested in participating/following the LSB. I hope
> we can get some additional C++ expertise from their participation.
>
> I am still working on the LSB "clean" headers that are based on the standard.
> Some link-line "clean" libraries are also coming along. The libs are actually
> generated from the interfaces listed in the DB. I hope to soon validate
> this concept by building some real (although small) apps using these
> headers/libs.
>
> I think that we agreed that libX11 and libXt belonged in the standard.
> Adding them to the doc is also on my to do list.
>
> One of the next issues that we need to decide is what precedence is given
> to the overlapping source standards. In places where SUS & POSIX overlap,
> which one has priority? There are places where one is less specific or allows
> some leeway to the implementation. We need to define how these differences
> should be resolved.
I think that SUS should take precedence over POSIX. The reasons are a
couple: SUS is newer, it is designed to augment and update existing POSIX,
and is the current standard in the UNIX world at large (so if we conform
more to SUS than POSIX, our apps are more source compatible with
commercial UNIXen).
> We haven't discussed this yet, but I would like to propose that we add
> OpenGL & Motif as optional components. Mesa & OpenGL use different library
> names which make it difficult for an application to be built to use both.
> The libraries are compatable, just named differently. This is the same problem
> we have with libc, just at a "higher" level. Same thing occurs with LessTif
> and Motif (an possibly other Motif clones). Since this is a "conflict of
> interest" area for me , I will not push for these if there is any resistance.
> It just seems like another instance of the problem we are working to solve,
> and other ABIs have included Motif in the past. As with the other interface
> lists, the list will be produced by comparing all implementations.
I don't think either of these are a good idea. Sure, it would be possible
to use Mesa and/or Lesstif, but at its hears Motif is a commercial
product, and I think OpenGL is too(?). In general, I think it would be a
good idea to hold off on including any X toolkits (besides the base ones)
until at least KDE/GNOME stuff begins to settle down.
+-----------------------------+--------------------------------+
| Jakob 'sparky' Kaivo | jake@nodomainname.net |
| NoDomainName Networks | http://www.nodomainname.net |
+-----------------------------+--------------------------------+
Reply to: