Re: [GRIDRPC-WG] GridRPC document (Re: [wg-all] New documents published)
Dear all, We have checked with Dan and indeed Greg didn't send the last document. I did it. Nevertheless the remark about the Persitent and Sticky still true. From my point of view: GRPC_Persitent means that the data is available in the platform. This data can move. Thus the middleware should manage this data as asked page 6 of the standard "The underlying data middleware is explicitly asked to handle the data" (I'm agree with that, I don't see another other way). GRPC_STICKY means that the data is available and can not move ! I found nothing in the document that explains that the data must be handle by the user (and it's sound good for me). From my point of view GRPC_STICKY is handle by the user or by the middleware. It depends on the implementation. I agree with Yves but somewhere, I am a little bit confuse if a data mode implies a behavior rule of the middleware usage. If I want to have a Sticky data somewhere but I don't care about where. I don't give the target of the data (the middleware will do it) or if I give both informations target and sticky mode then I manage myself the data. No ? Eddy Regards, Le 23 mars 2011 à 10:26, Yves Caniou a écrit :
Hello,
Not rude remarks here, but I'm a bit confused: it seems that Dan read an old version of the document? - I can't find the typo in the URI - I can't find the "To discuss:" that he's talking about. But it reminds me of the paragraph that I put there from the beginning concerning the diffusion of a data on the servers (Broadcast, multicast, and such things that were available in OmniStorage)...
BUT, concerning the distinction between GRPC_Persistent and GRPC_Sticky: if we have to emphasize that the second one is when the user completely relies on the data manager on the opposite of the second one where he manages himself the data, can't we have a data managed by the underlying data manager (transparent transfer) with some particularities (like if making the data sticky or unique if the DM wants to migrate the data)?
Cheers.
.Yves.
Le Wednesday 23 March 2011 02:26:15 Eddy Caron, vous avez écrit :
Dear all,
We have received the final comment from Dan. With Yves we will update the document to take into account these comments.
Best Regards, Eddy
Début du message réexpédié :
De : "Daniel S. Katz" <dsk@ci.uchicago.edu> Date : 22 mars 2011 11:21:57 UTC+08:00 À : Greg Newby <newby@arsc.edu> Cc : Eddy Caron <Eddy.Caron@ens-lyon.fr>, Alan Sill <Alan.Sill@ttu.edu>, Wolfgang Ziegler <Wolfgang.Ziegler@scai.fraunhofer.de> Objet : Rép : GridRPC document (Re: [wg-all] New documents published)
Hi,
I think it generally looks fine, and the GrdiRPC session today was helpful. Some specific issues I have:
On page 6, the distinction between GRPC_Persistent and GRPC_Sticky is not clear.
On page 7, "“http://myName:/myhome/data/matrix1”" has an extra ":" in the middle.
On page 11, the items under "to discuss:" are confusing. It seems like these should be resolved at this point, or marked as potential extensions. Also, in the second item, the "on" should be "one".
Dan
-- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/
--------------------------------------------------------------------------- ------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] --------------------------------------------------------------------------- ---------------------
-- Yves Caniou Associate Professor at Université Lyon 1, Member of the team project INRIA GRAAL in the LIP ENS-Lyon, Délégation CNRS in Japan French Laboratory of Informatics (JFLI), * in Information Technology Center, The University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan tel: +81-3-5841-0540 * in National Institute of Informatics 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan tel: +81-3-4212-2412 http://graal.ens-lyon.fr/~ycaniou/
---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------
On Mar 23, 2011, at 12:33 PM, Eddy Caron wrote:
Dear all,
We have checked with Dan and indeed Greg didn't send the last document. I did it.
Yes, sorry about this - I should have checked to make sure I had the right version, and even more, the "to discuss" should have been a flag that I didn't.
Nevertheless the remark about the Persitent and Sticky still true.
From my point of view:
GRPC_Persitent means that the data is available in the platform. This data can move. Thus the middleware should manage this data as asked page 6 of the standard "The underlying data middleware is explicitly asked to handle the data" (I'm agree with that, I don't see another other way).
GRPC_STICKY means that the data is available and can not move ! I found nothing in the document that explains that the data must be handle by the user (and it's sound good for me). From my point of view GRPC_STICKY is handle by the user or by the middleware. It depends on the implementation.
I agree with Yves but somewhere, I am a little bit confuse if a data mode implies a behavior rule of the middleware usage. If I want to have a Sticky data somewhere but I don't care about where. I don't give the target of the data (the middleware will do it) or if I give both informations target and sticky mode then I manage myself the data. No ?
Eddy Regards,
Le 23 mars 2011 à 10:26, Yves Caniou a écrit :
Hello,
Not rude remarks here, but I'm a bit confused: it seems that Dan read an old version of the document? - I can't find the typo in the URI - I can't find the "To discuss:" that he's talking about. But it reminds me of the paragraph that I put there from the beginning concerning the diffusion of a data on the servers (Broadcast, multicast, and such things that were available in OmniStorage)...
BUT, concerning the distinction between GRPC_Persistent and GRPC_Sticky: if we have to emphasize that the second one is when the user completely relies on the data manager on the opposite of the second one where he manages himself the data, can't we have a data managed by the underlying data manager (transparent transfer) with some particularities (like if making the data sticky or unique if the DM wants to migrate the data)?
Cheers.
.Yves.
Le Wednesday 23 March 2011 02:26:15 Eddy Caron, vous avez écrit :
Dear all,
We have received the final comment from Dan. With Yves we will update the document to take into account these comments.
Best Regards, Eddy
Début du message réexpédié :
De : "Daniel S. Katz" <dsk@ci.uchicago.edu> Date : 22 mars 2011 11:21:57 UTC+08:00 À : Greg Newby <newby@arsc.edu> Cc : Eddy Caron <Eddy.Caron@ens-lyon.fr>, Alan Sill <Alan.Sill@ttu.edu>, Wolfgang Ziegler <Wolfgang.Ziegler@scai.fraunhofer.de> Objet : Rép : GridRPC document (Re: [wg-all] New documents published)
Hi,
I think it generally looks fine, and the GrdiRPC session today was helpful. Some specific issues I have:
On page 6, the distinction between GRPC_Persistent and GRPC_Sticky is not clear.
On page 7, "“http://myName:/myhome/data/matrix1”" has an extra ":" in the middle.
On page 11, the items under "to discuss:" are confusing. It seems like these should be resolved at this point, or marked as potential extensions. Also, in the second item, the "on" should be "one".
Dan
-- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/
--------------------------------------------------------------------------- ------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] --------------------------------------------------------------------------- ---------------------
-- Yves Caniou Associate Professor at Université Lyon 1, Member of the team project INRIA GRAAL in the LIP ENS-Lyon, Délégation CNRS in Japan French Laboratory of Informatics (JFLI), * in Information Technology Center, The University of Tokyo, 2-11-16 Yayoi, Bunkyo-ku, Tokyo 113-8658, Japan tel: +81-3-5841-0540 * in National Institute of Informatics 2-1-2 Hitotsubashi, Chiyoda-ku, Tokyo 101-8430, Japan tel: +81-3-4212-2412 http://graal.ens-lyon.fr/~ycaniou/
---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------
-- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
-- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/ -- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/
participants (2)
-
Daniel S. Katz -
Eddy Caron