- gridrpc-wg - lists.ogf.org

Meeting at GGF16
by Hidemoto Nakada 17 Feb '06

17 Feb '06

All, We had a good F2F meeting at GGF16, Athens, For those who came the meeting, thanks. For those who could not make it, see you in Tokyo. You can find all the materials shown at the meeting on the gridforge. https://forge.gridforum.org/projects/gridrpc-wg/ + In summary we had three presentations, - data handle proposal from DIET team, - data handle implementation with Global file system from Ninf team - users experience by Rosa. + we also talked about collaborations with SAGA-RG. The GFSG (and our area director?) want to have API WGs under the SAGA-RG umbrella to have shared look and feel API set. Our options are - Recharter to have 'defining SAGA-style API' in the scope and do it. once the 'SAGA-style' is established, it will not that difficult since the concept is really similar to the one we already have. - Just give some advice them and go our own way. If you have opinion, please state on the list. + Our area director want to have our end-user API as a 'real' recommendation (may be as a guinea pig :) ). For that, we have to write some more documents. Thanks - hidemoto

1 0

None
by yoshio.tanaka＠aist.go.jp 12 Feb '06

12 Feb '06

Me

1 0

GridRPC Implementations
by Steven Newhouse 12 Feb '06

12 Feb '06

The Steering Group is collecting a list of which GGF specifications have been implemented. If you are doing an implementation, or know of one, could you please drop a short note to the list. Thanks, Steven & Dieter Applications Area Directors

3 2

Meeting agenda for GGF16
by Hidemoto Nakada 07 Feb '06

07 Feb '06

All, GGF16 in Athene is quickly approaching. We will have one session at Tuesday evening, from 17:30 to 19:00, in Olympia B. The main agenda will be the data-handle issue. I expect to have a proposal from Diet team, and a presentation on data-handle implementation with a global file system from Ninf team. We also will have a presentation from a GridRPC user! Dr. Rosa M. Badia from Barcelona Supercomputing Center will give us a presentation on her experience with GridRPC. See you there! -Hidemoto

1 0

GGF16
by guru prasad 07 Jan '06

07 Jan '06

Hello, Can anyone please send me the latest version of the document that will be used for discussion in GGF16. Thanks, Guru --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

1 0

session at GGF16
by Hidemoto Nakada 06 Dec '05

06 Dec '05

All, I've made request for a session on GridRPC-WG at GGF16 Athens. See you there! -hidemoto

1 0

Re: [saga-rg] Task model...
by Andre Merzky 01 Dec '05

01 Dec '05

Hi Pascal, Quoting [Pascal Kleijer] (Nov 11 2005): > > Hello, > > If you are working on a C++ model why work with flags? Simply use the > power of the language and use inheritance. A core abstract class give > the general common stuff and then you can derivate as wished to a > synchronous and asynchronous class. > > In that case the calls can remain the same but the behavior changes: > > saga::directory d= new SynchronousDirectory() > or > saga::directory d= new AsynchronousDirectory() > > > std::list<string> l; > saga::task t = d.list(&l); > t.wait(); > do something with l > > In the synchronous case the list is filled up and in the asynchronous > case the list will be filled only after the task has properly ended. > Calling the wait on the sync task will directly return. What about our example of doing a sync seek, then a async write on a file? saga::file f1 = new saga::SyncFile (url); saga::file f2 = new saga::AsyncFile (url); f1.seek (100, SEEK_CUR); saga::task t = f2.read (100, buffer); f2 still stands on the 0 position. So you can't mix sync and async calls on a object in that way. Also, your sync calls do return a task (probably finished), not an error code. Well, that problem pops up in most proposals we have so far... > So: > 1) You have uniformed calls. > 2) You can overwrite the class without affecting the definition. > 3) You can interchange the classes without touching your code. Right, good points... > Having the sync flag set on the fly and change the behavior might be > very difficult to handle in case of race conditions. I'm used to code > multi-tasked applications that often share numerous objects and changing > the sync/async behavior will be a real problem if you don't take > care. Debug that sort of code is hell. Yes, agree. Nobody really seems to like flags in terms of implementation. But well, it looks simple on API level, that the appealing part... Thanks, Andre. > my 2ct. > > 'Andre Merzky' wrote: > >Hmm, I thought so as well, you know. But actually, error > >conditions are flagged by excptions, so we would not return > >errors anyway. So it does not matter if e.g. mkdir_sync () > >returns a task: it would not be used anyway. (If the task > >gets returned it is Finished. If it failes, an error is > >thrown.) > > > >OTOH, for calls which do return infos this is different: > >directory.ls (); would normally return a list of strings I > >guess. With the proposed model, the list would need to be > >returned in I/O parameters, such as: > > > > std::list<string> l; > > d.ls_sync (&l); > > > >So, the problems are not error conditions, but return values > >I guess. > > > >However, similar considerations hold for the other task > >models: at least the signature of the method calls might > >look different for synchroneous and asynchroneous calls: > > > > sync in version B: > > > > std::list<string> l = d.sync.ls (); > > > > async in version B: > > > > std::list<string> l; > > saga::task t = d.sync.ls (&l); > > > >I created some more verbose examples at > > > > http://wiki.cct.lsu.edu/saga/space/Task+Models > > > >(see bottom of page) -- I hope that helps the discussion. > >Feel free to change/edit/correct them, and in fact to edit > >that page. > > > >Again: the cuurent discussion does ONLY affect the C++ > >language binding for now! > > > >Cheers, Andre. > > > > > > > >Quoting [Hartmut Kaiser] (Nov 08 2005): > >>The main question is, do we need to have different return values from > >>sync/async operations or not. It's kind of unusual to get a task from a > >>'normal' sync operation, even more because this task is usable for return > >>value retrieval only. > >> > >>Regards Hartmut -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

SAGA F2F at SC05 - ROOM CHANGE!
by Andre Merzky 16 Nov '05

16 Nov '05

Hi all, good news: thanks to Julie Wulf we got a room on-site at SC-05, which will simplify attendance for a number of people :-). So, we meet in +----------+ | Room 205 | +----------+ at the Convention Center, on Thursday from 13:00 to 18:00. A number of people have conflicts: don't hesitate to drop in part-time... Please note that there will be no power in the room... :-( Cheers, Andre. ----- Forwarded message from Julie Wulf-Knoerzer <wulf(a)ggf.org> ----- > Date: Wed, 16 Nov 2005 11:21:22 -0600 > To: Andre Merzky <andre(a)merzky.net> > From: Julie Wulf-Knoerzer <wulf(a)ggf.org> > Subject: Re: Room for Thursday > > I've reserved room 205 (across from where the GFSG f2f was). > Note there is no power strips in the room. If anyone asks, > you are with me (-: > > Julie ----- End forwarded message ----- -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

Fwd (andre@merzky.net): Re: [saga-rg] Meeting at SC05 - Reminder
by Andre Merzky 10 Nov '05

10 Nov '05

Hi, FYI, the final meeting details for the SAGA F2F meeting at SC05: Location: Room 526 (Emerald Suite) 6th Avenue Inn 2000 6th Avenue, Seattle, WA 98121 (green location on the map) Time: 13:00 to 18:00 Agenda: - WG charter (finalize) - SAGA task model (finalize) - use case evaluation (update, feed into req. doc) The attached map shows the convention center in orange, and the meeting location in green. Cheers, cu next week :-) Andre. On Nov 8, 2005, at 10:48 PM, Andre Merzky wrote: > > Hi all, > > this is just a reminder (and confirmation) that we will have > a SAGA F2F meeting in Seattle on Thursday, November 17th 2005. > We will meet in Ed's hotel suite (it will have a small > meeting room), I'll send the exact location (room number) as > soon as I know it. > > Cheers, cu next week, > > Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

Re: [saga-rg] Task model...
by 'Andre Merzky' 09 Nov '05

09 Nov '05

Hmm, I thought so as well, you know. But actually, error conditions are flagged by excptions, so we would not return errors anyway. So it does not matter if e.g. mkdir_sync () returns a task: it would not be used anyway. (If the task gets returned it is Finished. If it failes, an error is thrown.) OTOH, for calls which do return infos this is different: directory.ls (); would normally return a list of strings I guess. With the proposed model, the list would need to be returned in I/O parameters, such as: std::list<string> l; d.ls_sync (&l); So, the problems are not error conditions, but return values I guess. However, similar considerations hold for the other task models: at least the signature of the method calls might look different for synchroneous and asynchroneous calls: sync in version B: std::list<string> l = d.sync.ls (); async in version B: std::list<string> l; saga::task t = d.sync.ls (&l); I created some more verbose examples at http://wiki.cct.lsu.edu/saga/space/Task+Models (see bottom of page) -- I hope that helps the discussion. Feel free to change/edit/correct them, and in fact to edit that page. Again: the cuurent discussion does ONLY affect the C++ language binding for now! Cheers, Andre. Quoting [Hartmut Kaiser] (Nov 08 2005): > > The main question is, do we need to have different return values from > sync/async operations or not. It's kind of unusual to get a task from a > 'normal' sync operation, even more because this task is usable for return > value retrieval only. > > Regards Hartmut -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0