I think we can live without "deleteProject" since they are just containers of experiments.
How about archiveExperiment(expId) instead of deleteExperiment(expId)? This could be implemented in few different ways, but it would not involve the complications of deleting the experiment. Marlon On 5/23/14 8:37 AM, Suresh Marru wrote: > On May 19, 2014, at 5:39 PM, Marlon Pierce <[email protected]> wrote: > >> We need to be able to delete projects and experiments, but there are no >> API methods for this. I realize this is raises some problems for >> experiments that have been launched (I put this in the API summary [1], >> but I suggest the following intermediate steps: > For the reasons stated in the doc, delete is complex. How about the following > to start with: > >> * Have a method to delete Experiments that have not been launched yet. > How about deleteExperiment($experimentID) - currently only support delete > unlaunched. In the future we may want to mark a flag “active” to true or > false base on if anything is going on with this experiment. I feel this is > more authoritative then statuses. For instance, there can be race conditions > on states changes and delete actions. Instead, we can make this simple by > having a semaphore on an active flag. > >> * Have a method to delete Projects that only consist of unlaunched >> Experiments. > I think cascade deletion of projects and experiments within it (even > conditional delete) will need to thought out more. How about we only deletion > of empty projects for now? That means, the gateway is expected to delete all > experiments and then the project. Not optimal but to minimize side effects > for now. > > Suresh > >> * Otherwise, throw Exceptions ("Can only remove unlaunched experiments", >> "Can't remove projects that contain launched experiments"). >> >> Marlon >> >> [1] >> https://cwiki.apache.org/confluence/display/AIRAVATA/Airavata+API+Overview
