On Jun 13, 2005, at 10:00 AM, Andre Merzky wrote:
<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.