From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 24 Aug 1998 23:47:40 +0200

Re: debugging libggi...

Steve Cheng wrote:
> 
> On Sun, 23 Aug 1998, Marcus Sundberg wrote:
> 
> > Yes, I've though about that too. Internal tags should not be
> > visible to applications though. How about just adding an
> > int *idtag;
> > entry to the ggi_db_list (idtag will be an array with each
> > entry corresponding to an entry in bufs) ?
> 
> Question:
> 
> Does a DirectBuffer itself "belong" to a target, or it's entry in
> ggi_db_list ?
>
> If you're using int *idtag in ggi_db_list, then it's obviously the latter.

I'm not sure what you mean here?
A DirectBuffer is a structure that describes a memory region
on some hardware. Each structure is initialized by a library
and needs to be deinitialized by the same library. Therefore
the libraries need to know which buffers they have allocated,
in case another library moves them around.

Example:
X-target sets up two frames in ggi_db_list (buffer 0-1).
Extension foo gets attached and adds another buffer (2).
ggiSetMode is called, the X-target deletes buffer 0-1 and
adds two new buffers which will be 1-2, as foo's buffer is
now 0.

Then extension foo gets detached. How will it know which
buffer it shall delete?

This is why each library requests an idtag which it can mark
it's buffers with.

> But I think the former case is more useful/convenient, if you want to move
> buffers around or not have them in a ggi_db_list.  Is the paranoid
> encapsulation necessary?
> 
> e.g.
> 
> ggi_directbuffer *db = _ggi_db_get_new(int idtag);

ggi_db_list is meant for buffers that are automaticly available
as soon as the target is opened. If an extension has buffers
that are automaticly available as soon as it's attached it
shall also put it's buffers there so that the app can get them
with ggiDBGetBuffer().

Buffers that needs to be requested manually will not be in
this list, nor will they be handled by libggi. They will be
handled by one or more separate extensions.

ggi_db_list is not a "paranoid encapsulation", it's a way to
keep track of buffers without having every target implelenting
the same code.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se