-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
There's room for alot of elegant but complicated solutions. ;-)
First of all, encapsuling "g" is a good idea. We should hide the nitty-gritty
details behind a well-documented API. That would make InitNG less complicated.
For read-only access, I'd just declare a function that takes a function
pointer. This function takes care of iterating and just passes every element
in the persistent data list to the function pointer. We can specify what type
an element has and take care of datatype handling that way.
This model would also allow us to take transparently care of any threading
issues, synchronization or whatever problems might arise at some later point.
Well, what about this piece of real code just for the iterator stuff:
void initng_map_persistent(void (*yield)(persistent_item_t *));
I'm not quite sure what we need there, but probably it is enough to limit the
persistent API to the basic CRUD features and have the following API:
/**
* Add a new item to the persistent database.
*/
int initng_persistent_add( persistent_item_t* );
/**
* Remove an item from the database.
* TODO: Check by contents or just by address?
*/
int initng_persistent_remove( persistent_item_t* );
/**
* Replace one item in the persistent database with another.
*/
int initng_persistent_replace( persistent_item_t*, persistent_item_t* );
/**
* Iterate over the persistent database and pass every item to the yield
* function pointer.
*/
void initng_persistent_map( void (*yield)(persistent_item_t*) );
We can even create an API around the persistent_item_t thing to provide some
helper functions for copy and compare, e.g.:
/**
* Creates a deep copy of a persistent_item_t.
*/
persistent_item_t* initng_persistent_item_copy( persistent_item_t* );
/**
* Compares to items for equality of contents. Returns 0 if both items are the
* some, or a non-zero value otherwise.
*/
int initng_persistent_item_cmp( persistent_item_t*, persistent_item_t* );
Well, what about that? :-)
-- Eric
On Wed, Aug 12, 2009 at 04:09:28AM -0300, Ismael Luceno wrote:
> To improve the overall quality of the project, we should get rid of
> this global variable.
>
> It's a bit problematic, because it serves as a general way of accessing
> all the persistent (through the life of the process) data that InitNG
> uses.
>
> The simplest way to avoid this is to abstract the access to these
> variables through well defined functions.
>
> There are few options to do this, I think the following are viable:
>
> * A function that uses another function to iterate over the elements
> of the list (a la qsort).
> * A function that returns the needed data to iterate over the list,
> used by a macro to do the job.
> * <place here any other idea>
>
> This way we could simplify the design and avoid breaking the API so
> often.
>
> --
> Ismael Luceno
> --
> _______________________________________________
> Initng mailing list
> [email protected]
> http://jw.dyndns.org/mailman/listinfo/initng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
iEYEARECAAYFAkqCoOwACgkQhS0drJ3goJLcbACeNbE9PHp4i1Nm2VifkrfKp7ar
r5sAnRaosywT3H7DMJupxJ7LoOBk4B6s
=h1+U
-----END PGP SIGNATURE-----
--
_______________________________________________
Initng mailing list
[email protected]
http://jw.dyndns.org/mailman/listinfo/initng
