From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Fri, 26 Mar 1999 10:10:35 -0500 (EST)

Re: GGPG updated

On Thu, 25 Mar 1999, Jon M. Taylor wrote:
> 	In all the explanation of what a "visual" is, I didn't see the
> word "context" used once.  My impression was that the primary purpose of a
> visual was to serve as a unit of context, to which both LibGGI and any
> loaded extension libraries would bind arbitrary state info (via the
> "private" hook) and additional API functions and their implementations.

Correct.  I just simply neglected to use the word "context".

> I also thought that targets were just arbitrary sets of API implementations,
> not a fundamental representation of the underlying "back-end".  Just a
> convenient, flexible way to organize the API implementation code, in other
> words.  Is this wrong? 

The targets also contain the initialization code for the "back end"
which is called automatically when they are loaded.  So they are a 
slightly more than just a context and API implementation.

> 	All through the document, I saw a basic viewpoint put forward -
> that extension APIs should be 'generic'.  That is, they should be like
> LibGGI2D, which implements abstract drawing ops that can be applied to any
> target, accelerated or not.  I think this is too limiting.

Extensions are free to implement functionality that isn't available
on all "back ends", of course, I was just making the point that if 
it can be implemented, it should be, but I think that it was mentioned
that it is acceptable to do this in the HOWTO.  At the same time though, 
there is nothing gained by spinning off a whole slew of 1-card-only extensions
that all implement a superset of the same basic functions -- that 
should be done rather as extension targets to a more generic 
extension API, so a program using advanced features can run on more 
than one card (not necessarily all targets) by using that extension.

It is fully acceptible to take the one or two functions that card A
implements and no other card implements and put them in a separate
extension.  But at the same time, leaving room for other future 
drivers to hook into these advanced functions (e.g. not naming the
extension libGGIS3 but rather something more descriptive of
the functions it implements) is desirable.

> 	I feel that currently, a great deal of the functionality of many
> of the existing targets would be better implemented as extensions.  This
> point was brought home to me earlier this week, when I wanted to talk to
> my KGI driver outside of the scope of what the existing KGI target or the
> fbdev KGI helperlib could provide. 

Yes, that's what extensions are for, definitely.

> 	But then I thought, what if all KGI functionality was embodied in
> a LibKGI extension, and both the LibGGI and LibGGI3D KGI target code was
> just a thin wrapper around that API?  Then we would have all of the
> benefits of the existing target system, but I would also be able to access
> all of LibKGI's functionality on my own!  And there would be close to zero
> code duplication.  Most target code is concerned with implementing API
> calls, setup routines (hook API calls, init variables, hook visual
> context) and manipulating context in some way.  With an extension, you
> just put all the setup code in the ExtInit() call, put the context
> manipulation in your new API calls, and put any API extension
> functionality in overloaded functions just like the targets do now.

Doing that wouldn't buck any trends.

> 	Anyway, enough babble.  If anyone sees a flaw in my reasoning,
> please tell me now, because I am working on all this stuff already.  But
> if anyone should want to, say, write a LibMatrox or a LibS3Virge or
> something similar, I would be happy to help write LibMesaGGI support....

I don't think you're off track.  The only comment I have is that 
abstraction of features has benefits and should be done when 
appropriate.  It takes a bit of pondering to decide how to classify 
things but it's definitely worth doing; though feel-alike APIs
are cool to have, the ability to run the same source code on 
as many back ends as practical is what GGI is oriented towards,
so give that some thought.

--
P.C.M.C.I.A. stands for "Plastic Connectors May Crack If Adjusted"
                                                             -- me
--
Brian S. Julin