Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sat, 29 Aug 1998 18:29:54 -0700 (PDT)

Re: LibGGI2D, LibGGI3D and targets

On Sun, 30 Aug 1998, Marcus Sundberg wrote:

> Jon M. Taylor wrote:
> > 
> > On Sat, 29 Aug 1998, Marcus Sundberg wrote:
> >         Everything in CVS is a mess right now.  I suggest that we keep
> > working until we all agree that a suitable stable state has been reached,
> > and then we have Emmanuel blow away the whole CVS tree and reinstall
> > everything without kgi/, os/, lib/libggi/extensions/libggi2d, etc and with
> > any directory moves that we want done, done.  That will cost us our
> > revision control, but we can archive the old tree if necessary and the
> > cleanups will be worth it.
> 
> As Emmanuel has access to the server, isn't it possible to simply
> move/delete directories in the local filesystem? Or is this
> impossible?

	You lose all the RCS info, which IIRC invalidates all the change
sets for the whole archive. 
 
> > > The STUB libraries should always be loaded first by a target:
> > > Let's say that you have a binary-only target from libggi 2.0,
> > > that implements all libggi functions natively, and you upgrade
> > > to libggi 4.0, in which we for some reason decided that a
> > > ggiDrawParallelogram() function was badly needed.
> > >
> > > Now, the beauty of libggi is that as this target loads the
> > > stub.so library, you can use the new ggiDrawParallelogram() function
> > > even though the target doesn't even know it exists!
> > 
> >         I see.  But what if the API changes between versions?  Will the
> > old 2.0 DrawBox() be ignored, for example?
> 
> If the API of DrawBox _changes_, an old target will cause undefined
> results when used with new libggi. Maybe we should add versions to
> targets and other libraries too, to prevent an incompatible
> library from being loaded?

	Sounds like a good idea. 
 
> A new target used with an old libggi can handle the situation by
> providing both DrawBox() implementations and use the GGI_VERSION_FUNCS()
> macro to check which one to use.
>
> If DrawBox() is removed, and old target with new libggi will cause
> the DrawBox in the target to be unused, as there is no ggiDrawBox
> symobl in libggi. In this case you shouldn't use an old libggi with
> new targets - libggi is opensource and can always be upgraded.

	That makes more sense to me. 

Jon 

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

Index: [thread] [date] [subject] [author]