[gdome]RE: problem with user_data

[John Palmieri <johnp martianrock com>]

Well I read Luca's post from December and I have some input from my
point of view.  I'm not too solid on the meory mangement aspects of
Gdome but I am assuming nodes are derefrenced and then reloaded when a
user visits it again.  Correct me here if I am wrong.  The big problem
with the user_data is that it is just arbitrary data and as such can not
be easly serilized to support the same unloading and reloading that
nodes can support (I am still assuming nodes are reloaded dynamicly). 
Writting the memory block to a cache would be wrong because those values
could be pointers to pointers which would be bad.  In my case simple
properties would not work.  I need to support an OO api within the
user_data pointer.  My solution would be to create user_data as a base C
struct that held pointers to load and unload functions.  This struct
could be "inherited" by structs that wanted to extend the use of the
user_data:

typedef struct _UserData UserData;

struct _UserData {
     LoadFuncPtr load;
     LoadFuncPtr unload;
     void *user_data;
}     

typdef struct _MyUserData MyUserData;

struct _MyUserData {
     UserData inherit;
     int x;
     int y;
}

UserData *user_data;

MyUserData md = g_malloc( sizeof( MyUserData ) );

md->x = 1;
md->y = 2;

md->inherit->load = (LoadFuncPtr)on_my_data_load;

user_data =  (UserData *)md;
user_data->unload = (UnloadFuncPtr)on_my_data_unload;

Of course this all assumes that progs that use user_data would have to
be updated.  There is however another similar solution that would be
backwards compatable.  Instead of putting the function pointers for load
and unload in an inheritable struct they can be placed within the node
object and if not set to null run at the appropriate times.  This allows
for complex data types in user_data while giving extra functionality to
those who need to keep track of their userdata should the node be
derefrenced.

--
J5