[GRIDRPC-WG] Proposal for a Data Management API within the GridRPC

Eddy Caron Eddy.Caron at ens-lyon.fr
Thu Sep 20 19:46:25 CDT 2007


Dear Hidemoto and all,

Please find a new version of the document and following comments.  
This new version take into account  the helpful remarks of Hidemoto  
Nakada.


New version available here (version 0.3):

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf

Source files are available here :

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz

and a doc version (automatically generated with latex2rtf)  (few  
bugs, I work to fix them)

http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.doc

> I found several things to be addressed in the document.
>
> - function naming convention
>   the end user api uses
>    grpc_STRUCTURE-NAME_METHOD-NAME
>   style. I think, for users convenience, should be kept in the
>   middleware document.
>

In fact the naming convention was not applied everywhere to the  
previous API (grpc_cancel,grpc_get_error, grpc_probe_or, etc.) that  
explain why we have do this mistake. But I think it's a very good  
idea. Then now all function are designed as grpc_data_METHOD-NAME


> - constants
>   the constant values, such as 'PERSISTENT'  should be defined as
>   c macro, and have 'GRPC' as  prefix, to avoid conflicts with  
> other modules.
>

done

> - document structure.
>   I've  just insert the data handle document  as the chapter 3.
>   while the array arguements are discussed in other chapters.
>   we have to reconsider it.
>

Yes. I have the same difficulty. I have applied your remarks on the  
document before the merge. The current proposition can manage  
different kinds of data type: array and more. Thus the previous  
function designed only for array seems too restrictif and too static,  
isn't it ? I don't know how to keep both approaches.  We have work to  
design a complete API for data management with the following  
guidelines :

- A small number of functions
- A maximum of functionalities (every data management should be take  
into account)
- No link with a middleware
- As easy as possible

> - reference
>   I'm so novice that i do not know how to manage them. give me more  
> time.
>

It's fine if we continue to work on latex file. And I can convert in  
MSword version at each time that is required.

> anyway, please take a look, and give us comments.
>
> i'd like to revise this at least once before the F2F meeting in  
> Seattle.
>
>

Yes it's a great idea. If you have other remarks or If you think that  
we must keep the array function, let me know why and how.

We could discuss about other points :

	The title of your document is "A GridRPC Model and API for Advanced  
and Middleware Applications" but we focus only on data management at  
this time. What do you suggest ? We discuss about data mangement to  
find the best way for the GridRPC and we add the workflow management  
in the next version ?

I think we could give separate but complementary document. One for  
data management, another one for workflow management and so on.

About the remark from Yusuke Tanimura about the new error code, Yves  
should give a full answer.  He thinks it's not needed to modifiy the  
current API ( grpc_call() and grpc_call_async()) and I'm agree with  
him. But he will give more argmuments. We will discuss about that too.

Regards,
Eddy

> regards,
> -- 
>    HIDEMOTO NAKADA, GTRC, AIST
>
> 	
> 2007/7/21, Hidemoto Nakada <hide-nakada at aist.go.jp>:
>> Thanks Eddy,
>>
>> To keep track changes in documents,
>> OGF requires documents in Word.
>> I'll convert it into Word format, hopefully, within next two weeks.
>>
>> And, of course, we are waiting for your talk.
>>
>> have a good vacation!
>> --
>>    HIDEMOTO NAKADA, GTRC, AIST
>>
>>
>> 2007/7/21, Eddy Caron <Eddy.Caron at ens-lyon.fr>:
>>> Dear Hidemoto Nakada,
>>>
>>>         Yes it's a latex version. We can convert in .doc if  
>>> needed. With
>>> Yves Caniou we have corrected some part of the first version to take
>>> into account internal remarks from the GRAAL Team.
>>>
>>> New version available here (version 0.2):
>>>
>>> http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data.pdf
>>>
>>> Source files are available here :
>>>
>>> http://graal.ens-lyon.fr/~ecaron/GridRPC/GRPC_Data_OGF21.tar.gz
>>>
>>> With Yves Caniou and Frederic Desprez we attend to OGF21 and we can
>>> give a talk around this document. Could you keep a slot for this
>>> working group.
>>>
>>> Regards,
>>> Eddy
>>> PS: Just for information, I will be off line during the next two  
>>> week.
>>>
>>> Le 17 juil. 07 à 17:34, Hidemoto Nakada a écrit :
>>>
>>>> Eddy, could you send us the source (latex, i guess) file?
>>>>
>>>> thanks.
>>>> --
>>>>   HIDEMOTO NAKADA, GTRC, AIST
>>>>
>>>>
>>>> 2007/6/26, Eddy Caron <Eddy.Caron at ens-lyon.fr>:
>>>>> Dear GridRPC member,
>>>>>
>>>>>  From a preliminary version written by E Caron, F Desprez, JM
>>>>> Nicod and L
>>>>> Philippe we designed a new version of the proposal for a
>>>>> management of the
>>>>> API data in GridRPC. This new approach tries to take into account
>>>>> remarks
>>>>> from Craig  Lee and Hidemoto Nakada.
>>>>>
>>>>>  With the Graal team, I have organized the differents meeting and
>>>>> Yves
>>>>> Caniou resumed our ideas in this paper (thanks to him).
>>>>>
>>>>>  Many things have changed in this version and it's not a final
>>>>> version. But
>>>>> we need your remarks and comments to improve this document and
>>>>> finish it.
>>>>>
>>>>> Best regards,
>>>>> Eddy Caron and Yves Caniou
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> ---
>>>>> -------------------------
>>>>>
>>>>> Eddy Caron. Mcf ENS Lyon
>>>>>
>>>>> ENS Lyon - LIP - Projet GRAAL
>>>>>
>>>>> 46 Allee d'Italie, 69364 Lyon Cedex 07, France
>>>>>
>>>>> E-Mail : Eddy.Caron at ens-lyon.fr
>>>>>
>>>>> [ Tel : 04.72.72.84.96 ][ Web page :
>>>>> http://graal.ens-lyon.fr/~ecaron ]
>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> ---
>>>>> ---------------------------
>>>>>
>>>>> --
>>>>>   gridrpc-wg mailing list
>>>>>   gridrpc-wg at ogf.org
>>>>>   http://www.ogf.org/mailman/listinfo/gridrpc-wg
>>>>>
>>>>>
>>>
>>> -------------------------------------------------------------------- 
>>> ----
>>> ----------------------
>>> Eddy Caron. Mcf ENS Lyon
>>> ENS Lyon - LIP - Projet GRAAL
>>> 46 Allee d'Italie, 69364 Lyon Cedex 07, France
>>> E-Mail : Eddy.Caron at ens-lyon.fr
>>> [ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/ 
>>> ~ecaron ]
>>> -------------------------------------------------------------------- 
>>> ----
>>> ------------------------
>>>
>>>
>>
>> <Middleware_070828.doc>
> --
>   gridrpc-wg mailing list
>   gridrpc-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/gridrpc-wg

------------------------------------------------------------------------ 
----------------------
Eddy Caron. Mcf ENS Lyon
ENS Lyon - LIP - Projet GRAAL
46 Allee d'Italie, 69364 Lyon Cedex 07, France
E-Mail : Eddy.Caron at ens-lyon.fr
[ Tel : 04.72.72.84.96 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]
------------------------------------------------------------------------ 
------------------------



More information about the gridrpc-wg mailing list