Sorry, for the tardy response.

On Tue, 2005-15-02 at 21:47 +0100, Thomas Graf wrote:

I see, well I can extend my objects, I'm even willing to change the
architecture if needed. The only requirements from my side is to
keep the generic caching header to allow putting these objects into
generic caches and keep it simple to readd commit/rollback extesions
later on.

What is exactly required to make it GObject aware? I've never worked
with GOBject so far. Basically a qdisc looks like this at the moment:

struct rtnl_qdisc
{
	NLHDR_COMMON;		/* common fields required by cache */
	NL_TCA_GENERIC(q);	/* generic tc fields (parent, handle, ifindex ...) */
	void *opts;		/* qdisc specific options (e.g.  rtnl_sch_fifo) */
};

The NLHDR_COMMON must stay first, the ordering of the others doesn't
matter.

That could be a problem.  The GObject struct must be at the start so
that all sub-classes can be operated on with the g_object_ functions.
The only way to make these objects work with your caching scheme would
be to make a sub-class of GObject with the caching information.  This
would have the benefit of adding ref counting etc.

The following URL will give you a bit of background on GObject.
http://www.le-hacker.org/papers/gobject/

-- 
OpenPGP key: http://www.coverfire.com/files/pubkey.txt
Key fingerprint: FB0A 2D8A A1E9 11B6 6CA3  0C53 742A 9EA8 891C BD98