From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 29 Aug 1998 14:24:32 -0700 (PDT)

Re: LibGGI2D, LibGGI3D and targets

On Sat, 29 Aug 1998, MenTaLguY wrote:

> On Fri, 28 Aug 1998, Jon M. Taylor wrote:
> 
> > 	But the problem is that the targets implement an API with those
> > stubs, and the LibGGI2D API is different from the LibGGI3D and LibGWT
> > APIs.  Either you'd have to merge all LibGGIxx APIs into one for these
> > mega-targets, or have some way of implementing multiple versions of the
> > same target for the different LibGGIxx libraries, and if you are going to
> > do that last then why not separate the different targets and put them in
> > their LibGGIxx subdirectories?
> 
> Ah... now I see.  yes, it would probably be appropriate to keep the libGGI
> _STUBS_ (they are not the same as "targets", last I checked) 

	No they aren't.  Stubs are tied to a particular API.  A "target" 
is a somewhat nebulous term which refers to a base set of rendering
operations.

> with the
> appropriate extension library.  

	Right.  The stubs are ultra-simple, hardware/visual indpendent,
baseline implementations of the API functions.  Thus, they belong with the
extension library. 

> There certainly should be separate
> "foo-vendor-hw-(extension)" stubs for each extension.  

	Right.  Same for linear_16 and friends.  They are all tied to the
extention library's API.

> I dunno if they
> should be packaged with the extension library or with the KGI driver for
> sure or not.  

	I vote for the extension libraries.

> I guess it depends on the driver (i.e. would it come with the
> LibGGI distro, or is it third-party?), and the extension library (does it
> actually relate to specific hw or not?) 

	Right, but I still think it should all stay with LibGGI.  Other
non-GGI userspace code may want to hit the kgicon drivers directly, and
the people that use such code should not have to handle LibGGI-related
code if they will not be using it.  At least for now - at some point, the
amount of LibGGI[xx] extension and extension-target code will grow quite
huge, and we might want to begin distributing the extensions and/or the
vendor-specific driver libraries separately.  I would hate to see
kernel-like monolithic bloatage happen to the LibGGI source tree |-<.

Jon	

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed