On the correct usage of DAGDA

Some things to keep in mind when using DAGDA as data manager for DIET:

• All the data managed by DAGDA are entirely managed by DAGDA: The user don't have to free them. DAGDA avoids memory leaks, so the user does not have to worry about the memory management for the data managed by DAGDA.
• When using more than one DAGDA component on a node, the user should define a different storage directory for each component. For example, the Master Agent and one SeD are launched on the same computer: the user can define the storage directory of the Master Agent as ``/tmp/MA'' and the one for the SeD as ``/tmp/SeD1''. Do not forget to create the directories before to use DAGDA. This tip avoids many bugs which are really hard to find.
• The DAGDA API can be used to transfer the parameters of a service, but it should not be used as this. If an application needs a data which is only on the client, the user should transmit it through the profile. The DAGDA API should be used to share, replicate or retrieve an existing data. Using the API allows the user to optimize their applications, not to proceed to a diet_call even if it works fine. Indeed, the DAGDA client component is not linked to the DIET hierarchy, so using the API to add a data and then to use it as a profile parameter makes DAGDA to do additional and useless transfers.
• DAGDA can be used without any configuration, but it is always a good idea to define all the DAGDA parameters in the configuration files.

For any comment or bug report on DAGDA, please contact G. Le Mahec at the following e-mail address: gael.le.mahec@u-picardie.fr.