Expose node extended info

[vreixo]

Node extended info is a little structure to let applications to associate arbitrary data with an IsoNode. It is defined in node.h as:

struct iso_extended_info {
    /**
     * Next struct in the chain. NULL if it is the last item
     */
    IsoExtendedInfo *next;
    
    /**
     * Function to handle this particular extended information. The function
     * pointer acts as an identifier for the type of the information. Structs
     * with same information type must use the same function.
     * 
     * @param data
     *     Attached data
     * @param flag
     *     What to do with the data. At this time the following values are 
     *     defined:
     *      -> 1 the data must be freed
     * @return
     *     1
     */
    int (*process)(void *data, int flag);
    
    /**
     * Pointer to information specific data.
     */
    void *data;
};

it is implemented as a chained list, where the "process" function pointer is a callback point, and let users to distinguish between different extensions.

This extended info can be useful in several situations. Just some example use cases:

Internal usage by libisofs:

* Storage of extra attributes per node, for example Mac or CD-XA attributes that usually won't be used. * Let the user set the low level ISO-9660 file name to be used for a node. This may be useful for multisession, as some users may expect the iso name to be preserved between sessions. * A backup application may want to provide a "backup time" to be stored in the image (RR supports that timestamp, that can't be mapped to any POSIX attribute).

In these cases, the extended info will be interpreted by the library, and may be actually translated as some attributes or behavior on generated image. The advantage versus adding this info as new IsoNode fields is to prevent an extra memory cost for attributes that won't be used in most cases.

For external apps:

* A backup application may want to provide a way to relate the IsoNode with the local path (IsoFileSource) they come from. Remember that only file content keeps track of the source it comes from. However, a backup application may feel useful to relate a directory, for example, to the source directory on the filesystem. That info could even be written to image, by means of a pre-processing, done by the application, that retrieves that info just before create the low level image, and adds it to a hidden file that is included into image. That way, when the user wants to do an incremental backup, the app is able to know which local paths it must check for updates. * The above is also useful for multisession images. It is like the way Nero Burning ROM app works. When you insert a ms CD, it checks for possible changes in the local files from which the old session has been created. * A GUI application, such as faisca/saphira, may want to provide an Icon to any node, based on its type. The extended info is a good place to store it.

In these cases, it is the app who manages the attributes, usually libisofs just stores them, without further processing. Anyway, this may change in a future.

On the other side, this structure adds a little memory cost (a pointer per IsoNode), even if it is not used at all. On a big 100,000 files images, this means only 8K on a 64 bits system, so in my opinion this should be added inconditionally.

[vreixo]

Implemented in revision 388 of my branch.

[jing]

The first  dog training supplies you should buy, before you even bring the dog home, are a food and water bowl, collar, leash, food and a bed.

[jessica]

 jobs for 14 year olds  Jessica's Blog  jessica Blog