[SalesForce] Calling another batch from the execute method of another batch

UPDATED ANSWER

(not batch but...).

I was investigating the ScheduledDispatcher: https://gist.github.com/gbutt/11151983

And lo and behold this works:

global class ScheduledDispatcher Implements Schedulable{

    public Interface IScheduleDispached{
        void execute(SchedulableContext sc);
    }

    global void execute(SchedulableContext sc){
        Type targetType = Type.forName('{HANDLERNAME');
        if(targetType != null){
            IScheduleDispached obj = (IScheduleDispached)targetType.newInstance();
            obj.execute(sc);
        }
    }


}

public class {HANDLERNAME} implements ScheduledDispatcher.IScheduleDispached {

  public void execute(SchedulableContext sc)
    {

        //Call your Future Method Here

    } 

}

If you still need to do it from within the batch context you can do as previously suggested:

public static method1(){

   method2();

}

@future
public static method2(){

}

call method1 from the batch and method2 from elsewhere

Definitely you can use an HTTP callout as an escape mechanism. But this is pretty naughty. You'll need a Remote Site Setting and a Session ID and a global class etc etc etc (red flags, alarm bells).

May I humbly recommend the use of System.Queueable call instead of @Future. You can create a class that is constructed with any kind of argument that you want to hand in, like so:

public class DeferredHandler implements System.Queueable
{

    private Map<String,String> key2val;

    public DeferredHandler(Map<String,String> key2val) {
        this.key2val = key2val;
    }

    public void execute(System.QueueableContext objContext)
    {
        //do your @Future stuff here with this.key2val
    }

}

And invoke him from inside your batch like this:

//defer stuff
System.Queueable job = new DeferredHandler(key2val);
System.enqueueJob(job);

There is some literature about this in the docs and Josh Kaplan's awesome Queueable blog post.