[gridrpc-wg] Re: [saga-rg] Task model...

[Hidemoto Nakada]

Hi,

Andre Merzky wrote:
> Ah, right, sorry, I forgot about that model...
> 
> There are two points to it, really:  
> 
>   a) synchroneous calls alse return a (finished) task
>   b) a object can be either synchroneous or asynchroneous
> 
> (a) is actually a more general point: it would be
> interesting for the other models we listed earlier as well.
> I kind of like it, as it makes implementation simplier, but
> OTOH it makes error handlin somewhat more complex for the
> synchroneous case, as you need to query the task state and
> error condition explicitely.
> 
> (b) was indeed discussed, but if my memory does not trick
> me, it was discarded as it does not allow to 
> 
>   - create a directory object
>   - do a synchroneous mkdir
>   - copy 100 files asynchroneously into that dir

Why don't we simply have a 'sync' flag in the object, so that
we can change the mode of a object dynamically.

Directory d = new Directory("\");
      d.sync = false;
Task      t = d.mkdir("test\");
t.wait();

- hidemoto


> 
> you cannot mix sync and async calls in that model.  Is that
> something you would think is no problem?
> 
> We don't have very detailed use cases on asynchroneous
> calls, apart from what we learned from the GridRPC folx.  It
> might be worth to write some down explicitely...
> 
> Cheers, Andre.
> 
> 
> Quoting [Pascal Kleijer] (Nov 07 2005):
> 
>>Hello,
>>
>>Here is an example of what was discussed in Boston.
>>
>>// Type g1: No factory
>>// The class has a flag in the constructor to tell if it work
>>// synchronous or not.
>>Directory d= new Directory("\", true);
>>Task      t= d.mkdir("test\");
>>t.wait();
>>
>>//Type g2: with factory
>>DirectoryFactory  f= new SynchronousDirectoryFactory();
>>Directory         d= f.newInstance("\");
>>Task              t= d.mkdir("test");
>>t.wait();
>>
>>Whatever the nature of the call, synchronous or not, a task is returned. 
>>A synchronous call will return a finished task. By providing a tight 
>>encapsulation it is possible to sub-class easily to add new features. 
>>For example you can implement a DebugDirectory class easily adding some 
>>extra debugging information without having to change the main code.
>>
>>My preference goes to the g1 case since it is the most direct and no 
>>factory is needed. Pattern design (g2) is nice, but I'm not sure if this 
>>is really necessary for this model.
>>
>>I know this solution is really OO designed, but that?s just because I 
>>always think in terms of objects.
>>
>>
>>Best regards,
>>Pascal Kleijer
>>
>>
>>
>>>Hi Pascal, 
>>>
>>>there have been more models in discussion in Boston, true
>>>enough.  However, I can't really figure out what model you
>>>refer to.  Some example code would be helpful :-)
>>>
>>>Cheers, Andre.
>>>
>>>
>>>Quoting [pascal.kleijer at knd.biglobe.ne.jp] (Nov 03 2005):
>>>
>>>>Hello all,
>>>>
>>>>Lets enter the arena if it is not too late, sorry for that.
>>>>I do agree with many things that have been discussed here.
>>>>Being myself a POP (pattern oriented programming) and OOP
>>>>(Object Oriented programming) guy I tend to favor nicely
>>>>encapsulated models.
>>>>
>>>>As mentioned by Tom, the template is possible in Java as
>>>>well. But that forces the usage of Java 5.0 (aka 1.5) at
>>>>least. This isn't recommended since many programs
>>>>still run with 1.4. Using them would probably create a very
>>>>different binding in Java, C++ or Python, which would end up
>>>>in 2 different SAGA implementations/usage, one for OO
>>>>languages and one for old fashioned procedurals. 
>>>>
>>>>As to exposing the different implementation to the user I
>>>>think this could be avoided in OO languages, or at least it
>>>>should not be as obvious as in 4a2. During the GGF meeting
>>>>their was a last minute discussion about a `g' solution
>>>>which is pretty much pure OO design with a simple method
>>>>call whatever model is used.  This is I think a good choice
>>>>for an OO point of view. You can derivate an abstract class
>>>>to specialized classes with synchronous or asynchronous
>>>>implementation. This would even open the room for sub
>>>>classing it to add custom code for debugging for example or
>>>>other treatment without affecting the initial code.
>>>>Depending on how the programming is tackled factories aren't
>>>>necessary. The problem might come when implementation is
>>>>made in procedural languages, it might be necessary to add
>>>>additional parameters to the constructor or the calls.
>>>>
>>>>I don't have the time this morning to make a sample
>>>>code. But I hope you got the idea.
>>>>
>>>>Best Regards,
>>>>Pascal Kleijer
>>>>
>>>>
>>>>>My vote is for 4a1. (Which was option D in our original discussion I 
>>>>>believe.)
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Tom
>>>>>
>>>>>On Thu, 3 Nov 2005, Andre Merzky wrote:
>>>>>
>>>>>
>>>>>>Hi John, Thilo, Group,
>>>>>>
>>>>>>Hartmut and I would like to argue about the C++ bindings.
>>>>>>We would like to come to an agreement soon, as our
>>>>>>implementation is dealing with the async part right now.
>>>>>>
>>>>>>As reminder:
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>Example 4a: more versions in C++
>>>>>>
>>>>>>4a1:               d.mkdir         ("test/");
>>>>>>                 d.mkdir_sync    ("test/"); // same
>>>>>>saga::task t_1 = d.mkdir_async   ("test/");
>>>>>>saga::task t_2 = d.mkdir_task    ("test/");
>>>>>>
>>>>>>4a2:               d.mkdir         ("test/");
>>>>>>                 d.sync .mkdir   ("test/"); // same
>>>>>>saga::task t_1 = d.async.mkdir   ("test/");
>>>>>>saga::task t_2 = d.task .mkdir   ("test/");
>>>>>>
>>>>>>4a3:               d.mkdir         ("test/");
>>>>>>                 d.mkdir <sync>  ("test/"); // same
>>>>>>saga::task t_1 = d.mkdir <async> ("test/");
>>>>>>saga::task t_2 = d.mkdir <task>  ("test/");
>>>>>>---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>Quoting [John Shalf] (Nov 02 2005):
>>>>>>
>>>>>>>> Q5) Any comments to 4a1, 4a2 or 4a3? (not part of the Strawman!)
>>>>>>>
>>>>>>>I prefer 4a1 because it is more readable and the implementation would
>>>>>>>be quite straightforward.
>>>>>>
>>>>>>You favour 4a1.  We think that implementation is very straight
>>>>>>forward for all three versions.  Readability seems not much
>>>>>>different to me, and might largely be a matter of taste.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It is also a familiar paradigm for any MPI
>>>>>>>programmers and anyone who has played with various proprietary Async
>>>>>>>I/O implementations. (its a very familiar and conventional approach)
>>>>>>
>>>>>>Well, these are C-API's.  Is there a C++ binding for MPI,
>>>>>>and does it look the same?
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I kind of like 4a2 as well from the standpoint of a C++ programmer
>>>>>>>(even with Andre's syntax corrections).  However, the resulting
>>>>>>>bindings will not be very consistent with the approach we would take
>>>>>>>for Fortran or C bindings (eg. those would likely look more like
>>>>>>>4a1).
>>>>>>
>>>>>>But, well, that is the idea of the language binding!  I agree
>>>>>>that C and Fortran would look more like 4a1, of course.  But that
>>>>>>is no reason that C++ should look like that as well, or Java,
>>>>>>Perl etc.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It is not really much more readable than 4a1.  Therefore, I'm
>>>>>>>uncertain if it is worth fragmenting our approach to bindings in
>>>>>>>different languages when there is not a clear benefit in terms of
>>>>>>>readability or implementation complexity.
>>>>>>
>>>>>>I think that 4a2/4a3 actually allow nicer implementations, as it
>>>>>>allows to have the different async parts somewhat separate from
>>>>>>the sync parts.  We think its nicer :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I do a lot of C++ programming, but I find the 4a3 option a bit
>>>>>>>obscure both in terms of readability and any advantages it might
>>>>>>>confer in terms of implementation.
>>>>>>
>>>>>>Hehe - I thought the same :-)  Hartmut likes that version very
>>>>>>much.  To me it appealed after pondering over it for a couple of
>>>>>>days.  Now I think it is cute, and quite expressive.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>It would certainly be easier to
>>>>>>>create multi-language bindings for a single code base if we stick
>>>>>>>with something more conventional like 4a1.
>>>>>>
>>>>>>I think that C and Fortran bindings for this part are straight
>>>>>>forward anyway, there is no need to reflect that in C++...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Each approach is equally readable to me (less so for 4a3).  I'm
>>>>>>>certainly open to any additional information on how the 4a2 and 4a3
>>>>>>>approaches could simplify implementation.
>>>>>>
>>>>>>The main point really is that the object itself has only the sync
>>>>>>method calls, and the async calls can be put into separate
>>>>>>header/sources easily, and build (by default) on top of the sync
>>>>>>calls.  Of course, you can do that with all three versions, but
>>>>>>its not as obvious in 4a1.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>If the other approaches
>>>>>>>can offer some implementation benefits, then maybe I'd give them
>>>>>>>extra consideration, but otherwise, I would prefer a more
>>>>>>>conventional approach like 4a1.
>>>>>>
>>>>>>I would  vote for 4a2 or 4a3 (in that order), but 4a1 would be ok
>>>>>>if the majority likes that most, of course.  Basically its
>>>>>>a matter of taste I think.  I am happy that the general point
>>>>>>seems accaptable to all so far: having sync, async, and task
>>>>>>versions of the calls, w/o explicit task factory.
>>>>>>
>>>>>>
>>>>>>>The only implementation I'm outright
>>>>>>>against is the 4b example.
>>>>>>
>>>>>>Good! :-)
>>>>>>
>>>>>>Thanks, Andre.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-john
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
> 
> 
>