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
|