#308 COLLECTION - allow collection object to use memory functions provided by caller
Closed: wontfix 2 years ago by atikhonov. Opened 14 years ago by dpal.

It is a good practice to allow objects like collection integrate well with the memory management functions used by the application. There should be a way to set memory management functions for the collection interface to use.

Also it makes sense to allow different internal implementations of the collection.
The collection can be based not only on the link list as now but on the hash table or array.

It makes sense to implement this feature when libcollection is turned into a stand alone .so.

One of the early ideas of how it can look like was this:

/* Function that creates a named collection using a memory descriptor.
 * Will be added in future together with the definition of the
 * descriptor structure.
 * The purpose is to control the internal implementation of 
 * the collection
 * a) Use hash table for faster searches if the collection is 
 *    expected to be large.
 * b) Define memory functions to use.
 */

int col_create_collection_ex(struct collection_item **ci,
                             const char *name,
                             unsigned cclass,
                             struct cdescriptor *descrptor);

Fields changed

description: It is a good practice to allow objects like collection integrate well with the memory management functions used by the application. There should be a way to set memory management functions for the collection interface to use.

Also it makes sense to allow different internal implementations of the collection.
The collection can be based not only on the link list as now but on the hash table or array.

It makes sense to implement this feature when libcollection is turned into a stand alone .so.

One of the early ideas of ho it can look like was this:
{{{
/ Function that creates a named collection using a memory descriptor.
* Will be added in future together with the definition of the
* descriptor structure.
* The purpose is to control the internal implementation of the collection
* a) Use hash table for faster searches if the collection is expected to be large.
* b) Define memory functions to use.
/

int col_create_collection_ex(struct collection_item ci,
const char
name,
unsigned cclass,
struct cdescriptor
descrptor);
}}} => It is a good practice to allow objects like collection integrate well with the memory management functions used by the application. There should be a way to set memory management functions for the collection interface to use.

Also it makes sense to allow different internal implementations of the collection.
The collection can be based not only on the link list as now but on the hash table or array.

It makes sense to implement this feature when libcollection is turned into a stand alone .so.

One of the early ideas of ho it can look like was this:
{{{
/ Function that creates a named collection using a memory descriptor.
* Will be added in future together with the definition of the
* descriptor structure.
* The purpose is to control the internal implementation of
* the collection
* a) Use hash table for faster searches if the collection is
* expected to be large.
* b) Define memory functions to use.
/

int col_create_collection_ex(struct collection_item ci,
const char
name,
unsigned cclass,
struct cdescriptor
descrptor);
}}}

Fields changed

description: It is a good practice to allow objects like collection integrate well with the memory management functions used by the application. There should be a way to set memory management functions for the collection interface to use.

Also it makes sense to allow different internal implementations of the collection.
The collection can be based not only on the link list as now but on the hash table or array.

It makes sense to implement this feature when libcollection is turned into a stand alone .so.

One of the early ideas of ho it can look like was this:
{{{
/ Function that creates a named collection using a memory descriptor.
* Will be added in future together with the definition of the
* descriptor structure.
* The purpose is to control the internal implementation of
* the collection
* a) Use hash table for faster searches if the collection is
* expected to be large.
* b) Define memory functions to use.
/

int col_create_collection_ex(struct collection_item ci,
const char
name,
unsigned cclass,
struct cdescriptor
descrptor);
}}} => It is a good practice to allow objects like collection integrate well with the memory management functions used by the application. There should be a way to set memory management functions for the collection interface to use.

Also it makes sense to allow different internal implementations of the collection.
The collection can be based not only on the link list as now but on the hash table or array.

It makes sense to implement this feature when libcollection is turned into a stand alone .so.

One of the early ideas of how it can look like was this:
{{{
/ Function that creates a named collection using a memory descriptor.
* Will be added in future together with the definition of the
* descriptor structure.
* The purpose is to control the internal implementation of
* the collection
* a) Use hash table for faster searches if the collection is
* expected to be large.
* b) Define memory functions to use.
/

int col_create_collection_ex(struct collection_item ci,
const char
name,
unsigned cclass,
struct cdescriptor
descrptor);
}}}

Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred

Nice to have. No demand so far. Can be deferred.

proposed: => 2.0

Fields changed

milestone: SSSD Deferred => Tools Deferred

Fields changed

rhbz: => 0

Metadata Update from @dpal:
- Issue assigned to dpal
- Issue set to the milestone: Tools Deferred

7 years ago

Looks like there was no real demand for this improvement for a long time.

I'm closing this as "WONTFIX" keeping in mind we can re-open this later if needed.

Metadata Update from @atikhonov:
- Custom field component adjusted to None (was: libcollection)
- Custom field selected adjusted to None
- Custom field testsupdated reset (from 0)
- Custom field type adjusted to None (was: enhancement)
- Custom field version adjusted to None (was: 0.99.0)
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata