<snip>

Asynchroneousity (eng?) would be provided via the task

interface, as before (pseudocode):

sync:  File file (url);

       file.read (len, buff, &ret_len);

async: File            file (url);

       FileTaskFactory ftf  = file.createTaskFactory ();

       Task            task = ftf.read (len, buff);

       task.run  ();

       // do some other stuff here

       task.wait (&ret_len);

There are more methods on the Task interface, for non

blocking checks etc.  The task models holds for all saga

objects basically, so would also cover the eRead and eWrite

calls.

But this could take a *long* time, e.g. hours (you have to sort through 1TB of data, which is on a disk).  How would a client be able to tell what was going on?  Can I distinguish between:

a) The remote service is preparing the data for me

b) The network connection to the service has suddenly slowed down or broken, and the data can't get through.

I think if your API looks like:

1. PrepareData

2. GetData

then people are more likely to expect that the data preparation is going to take a while.

I'm not sure that just allowing the first read to take an hour is going to encourage people to build clients that can cope well with this.  I'd hit <CTRL-C> if I didn't have a better idea of what was going on.

Jon.