There is something wrong with the document posted on http://www.ggf.org/Public_Comment_Docs/Documents/Sep-2005/draft-ggf-saga-use -cases.pdf Starting on page 37, it is blank all the way to page 199. Apparently the conversion to pdf failed. Tomasz -----Original Message----- From: owner-saga-rg@ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of Ed Seidel Sent: Monday, October 24, 2005 8:30 AM To: Thilo Kielmann Cc: apps-rg@ggf.org; saga-rg@ggf.org Subject: Re: [saga-rg] SAGA use case document: comments needed! (this week) I'd like to encourage people to take this seriously and spend a little time on it. In my opinion, it is among the very important activities going on in GGF. SAGA specifically aims to support the developers of scientific applications, so it is very important to get as much feedback as possible from apps groups. We hope to develop APIs that are so compelling, that they will be available to and adopted by application developers everywhere. As SAGA has now turned into a Working Group, it is now developing what should turn out to be a standard. Please take some time to look at this, and give feedback on use cases so we can make this work well. Best, Ed On Oct 24, 2005, at 6:26 AM, Thilo Kielmann wrote:

Dear all,

the SAGA-RG has its use case document up for public comment, ending oct 30.

So far, there are 0 comments! :-(

I hereby urge everybody to have a look and comment, even if the comment is just trivially in favour...

Thanks for your help,

Thilo -- Thilo Kielmann http://www.cs.vu.nl/ ~kielmann/

Hi Tomasz, I've just downloaded this from the link you gave, and it works fine for me. Jon. On Oct 24, 2005, at 4:29 PM, Tomasz Haupt wrote:

There is something wrong with the document posted on http://www.ggf.org/Public_Comment_Docs/Documents/Sep-2005/draft-ggf- saga-use -cases.pdf

Starting on page 37, it is blank all the way to page 199. Apparently the conversion to pdf failed.

Tomasz

-----Original Message----- From: owner-saga-rg@ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of Ed Seidel Sent: Monday, October 24, 2005 8:30 AM To: Thilo Kielmann Cc: apps-rg@ggf.org; saga-rg@ggf.org Subject: Re: [saga-rg] SAGA use case document: comments needed! (this week)

I'd like to encourage people to take this seriously and spend a little time on it. In my opinion, it is among the very important activities going on in GGF. SAGA specifically aims to support the developers of scientific applications, so it is very important to get as much feedback as possible from apps groups. We hope to develop APIs that are so compelling, that they will be available to and adopted by application developers everywhere. As SAGA has now turned into a Working Group, it is now developing what should turn out to be a standard.

Please take some time to look at this, and give feedback on use cases so we can make this work well.

Best, Ed

On Oct 24, 2005, at 6:26 AM, Thilo Kielmann wrote:

...

Dear all,

the SAGA-RG has its use case document up for public comment, ending oct 30.

So far, there are 0 comments! :-(

I hereby urge everybody to have a look and comment, even if the comment is just trivially in favour...

Thanks for your help,

Thilo -- Thilo Kielmann http://www.cs.vu.nl/ ~kielmann/

On Nov 2, 2005, at 10:29 AM, Andrei Hutanu wrote:

Hi all, Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API

By "Block-based data transmission" to you mean a kind of "Reliable Messages" API as opposed to the existing Stream API? If so, would you want to support more complex semantics such as the WS standard? ftp://www6.software.ibm.com/software/developer/library/ws- reliablemessaging200502.pdf Or stick with simpler semantics like those offered by RUDP or RIPP?

Let me rephrase this a bit. Reliability is good and useful as an option (as is in order delivery) but shouldn't be a requirement. What this API should do is to remove the burden from the user to deal with arbitrary sizes of data such as : 1 byte (current API) or 1500/9000 bytes (UDP/RIPP) when using the network. Regardless of wether this finds it's way into the SAGA API or not I would like to propose a phone conference with all the interested parties to decide what this API should actually look like. Andrei Andrei Hutanu wrote:

Hi John,

I don't have reliability or in order-delivery as a requirement. The idea is that there is a sender, sending large (variable in size) chunks of binary data. On the receiving end either a chunk comes complete (even if it has some byte errors inside) or it doesn't come at all. Here is the tentative API I proposed (slightly modified from the original use case here). Does this make sense?

Start sending data asynchronously (cb gets called at the end of the operation)

AsyncResult beginSend (Block block, AsyncResultCallback cb, void* userData); // releases resources, should be called in the callback, if called before callback blocks endSend (AsyncResult handle); Same as with send : AsyncResult beginReceive (AsyncResultCallback cb, void* userData); Block endReceive (AsyncResult handle); typedef struct Block { const void* const buffer; size_t size; } Block;

John Shalf wrote:

...

On Nov 2, 2005, at 10:29 AM, Andrei Hutanu wrote:

...

Hi all, Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API

By "Block-based data transmission" to you mean a kind of "Reliable Messages" API as opposed to the existing Stream API?

If so, would you want to support more complex semantics such as the WS standard? ftp://www6.software.ibm.com/software/developer/library/ws- reliablemessaging200502.pdf

Or stick with simpler semantics like those offered by RUDP or RIPP?

Hi all, here is some more feedback to the API regarding the steering use-cases "Collaborative Visualization of Atmospherical Data" and "Computational steering of a ground water pollution simulation" Both use our VISIT toolkit for the communication and i looked at the Stream API to check, whether VISIT could be build on top of it. The overall answer is 'yes, but ...' there are mainly two things missing: * resource discovery (as Andrei also mentioned in his comment), we would need a functionality like: register(service_name, url); unregister(service_name, url); url = query(service_name); * in both use-cases there is an interactive visualisation/steering application sitting at one end of the stream. Such applications typically use some kind of GUI-toolkit with operates in an event-callback mode or similar, where callbacks can be registered for events occuring at socket/pipe/...-descriptors. On the other hand, in many implementations, a Stream will somehow use a socket, pipe or something else with a descriptor. Therefore we need a function that returns the descriptor associated to a stream: fd = descriptor(Stream); However, users have to be aware, that several Streams may share the same decriptor (e.g. in VISIT, if several Streams are tunneled through a single connection of a different protocol like ssh). * a general remark on Streams: i like the idea of keeping the Stream-API close to the BSD socket API. However, as Andrei mentioned, we also often have to deal with more message- or block-oriented communication patterns. In the internal API the we use in the VISIT toolkit, we have therefore added a timeout parameter to all functions and slightly changed the semantics. For example nread = read(stream, buffer, size, timeout); works as: try to read size bytes from stream, return if either: - size bytes have been read, or - timeout seconds have passed (wait forever, if timeout < 0), or - an error has occured the function returns the number of bytes read or -1 in case of an error. This differs from the normal BSD-read, which blocks until *some* data is available and return that data (but nor more than size bytes). We found that more convenient to implement synchronous message-oriented applications and 'normal' Stream communication with a single and straight-forward API. Best regards, Thomas Andrei Hutanu wrote:

Hi all,

Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API *Resource discovery is not covered by the current API *Job submission to multiple resources (co-scheduling) is not covered by the current API *Simple job submission seems to be covered by the API. Here is a list of things that are not covered (because outside the 80-20 rule?) and there doesn't seem to be a "generic" attribute in the JobDefinition class where these attributes could be specified if the underlying scheduler happens to support them. ** Logical file requirement (the jobs needs to run on a machine where an instance of this particular logical file exists) ** Graphics requirements ** Networking requirements (network interface, bandwidth to ..) ** Performance-based descriptions : GFlops, memory bandwidth ..

Andrei

Thilo Kielmann wrote:

...

Dear all,

the SAGA-RG has its use case document up for public comment, ending oct 30.

So far, there are 0 comments! :-(

I hereby urge everybody to have a look and comment, even if the comment is just trivially in favour...

Thanks for your help,

Thilo

------------------------------------------------------------ Dr. Thomas Eickermann Zentralinstitut fuer Angewandte Mathematik Forschungszentrum Juelich GmbH D-52425 Juelich Phone: +49 2461 61-6596 Email: Th.Eickermann@fz-juelich.de Fax: +49 2461 61-6656

Hi Thomas, sorry for the late answer... *sigh* Quoting [Thomas Eickermann] (Nov 10 2005):

Hi all,

here is some more feedback to the API regarding the steering use-cases "Collaborative Visualization of Atmospherical Data" and "Computational steering of a ground water pollution simulation" Both use our VISIT toolkit for the communication and i looked at the Stream API to check, whether VISIT could be build on top of it.

The overall answer is 'yes, but ...' there are mainly two things missing:

* resource discovery (as Andrei also mentioned in his comment), we would need a functionality like: register(service_name, url); unregister(service_name, url); url = query(service_name);

Yes, that is indeed completely missing. I put a more explicit TODO item in our issue list.

* in both use-cases there is an interactive visualisation/steering application sitting at one end of the stream. Such applications typically use some kind of GUI-toolkit with operates in an event-callback mode or similar, where callbacks can be registered for events occuring at socket/pipe/...-descriptors. On the other hand, in many implementations, a Stream will somehow use a socket, pipe or something else with a descriptor. Therefore we need a function that returns the descriptor associated to a stream: fd = descriptor(Stream);

This is complicated, as we do not know _if_ there will be a native descriptor available, and if operations on that will interfere with the implementation. E.g. the implementation might be based on Globus-XIO or on Reliable UDP. For the first I do not know if a descriptor is availbale via the API, for the second there are two descriptors (one tcp, one udp) the application would need to handle. Also, the implementation might transparently add a protocol (say checksumming), and direct tempering with the desfriptor might very well break that protocol. So, we might be able to add the API function, but it is difficult to define what it should return in the cases outlined above...

However, users have to be aware, that several Streams may share the same decriptor (e.g. in VISIT, if several Streams are tunneled through a single connection of a different protocol like ssh).

* a general remark on Streams: i like the idea of keeping the Stream-API close to the BSD socket API. However, as Andrei mentioned, we also often have to deal with more message- or block-oriented communication patterns. In the internal API the we use in the VISIT toolkit, we have therefore added a timeout parameter to all functions and slightly changed the semantics. For example

nread = read(stream, buffer, size, timeout);

works as: try to read size bytes from stream, return if either: - size bytes have been read, or - timeout seconds have passed (wait forever, if timeout < 0), or - an error has occured the function returns the number of bytes read or -1 in case of an error.

This differs from the normal BSD-read, which blocks until *some* data is available and return that data (but nor more than size bytes).

We found that more convenient to implement synchronous message-oriented applications and 'normal' Stream communication with a single and straight-forward API.

Thanks for this feedback! You may have seen the mail exchange to that topic. If you are interested, could you give us your feedback to the proposal written down at: http://wiki.cct.lsu.edu/saga/space/SAGA+API/Messages Best regards, Andre.

Best regards, Thomas

Andrei Hutanu wrote:

...

Hi all,

Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API *Resource discovery is not covered by the current API *Job submission to multiple resources (co-scheduling) is not covered by the current API *Simple job submission seems to be covered by the API. Here is a list of things that are not covered (because outside the 80-20 rule?) and there doesn't seem to be a "generic" attribute in the JobDefinition class where these attributes could be specified if the underlying scheduler happens to support them. ** Logical file requirement (the jobs needs to run on a machine where an instance of this particular logical file exists) ** Graphics requirements ** Networking requirements (network interface, bandwidth to ..) ** Performance-based descriptions : GFlops, memory bandwidth ..

Andrei

Thilo Kielmann wrote:

...

Dear all,

the SAGA-RG has its use case document up for public comment, ending oct 30.

So far, there are 0 comments! :-(

I hereby urge everybody to have a look and comment, even if the comment is just trivially in favour...

Thanks for your help,

Thilo

------------------------------------------------------------ Dr. Thomas Eickermann Zentralinstitut fuer Angewandte Mathematik Forschungszentrum Juelich GmbH D-52425 Juelich Phone: +49 2461 61-6596 Email: Th.Eickermann@fz-juelich.de Fax: +49 2461 61-6656

-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

Hi Thomas, Quoting [Thomas Eickermann] (Dec 02 2005):

Hi Andre,

thanks for your answer. I agree with your comments that access to raw descriptors is somewhat problematic. Nevertheless i regard them as quite important for implementing real-life interactive applications. Two examples:

1. AVS/Express allows to trigger a module if an event occurs at a descriptor. I do not know of any other way to implement stream communication within AVS/Express and i imagine, that the situation is quite similar for other tools like OpenExplorer.

2. If you use some GUI toolkit (e.g. Qt), you can also register callbacks for events on descriptors. If such a descriptor is not available, the only thing you can probably do is to use timers and polling. There are obviously good reasons to avoid that, if possible.

I agree about the importance.

See further comments inline.

Best regards, Thomas

Andre Merzky wrote:

...

Hi Thomas,

sorry for the late answer... *sigh*

Quoting [Thomas Eickermann] (Nov 10 2005):

...

* in both use-cases there is an interactive visualisation/steering application sitting at one end of the stream. Such applications typically use some kind of GUI-toolkit with operates in an event-callback mode or similar, where callbacks can be registered for events occuring at socket/pipe/...-descriptors. On the other hand, in many implementations, a Stream will somehow use a socket, pipe or something else with a descriptor. Therefore we need a function that returns the descriptor associated to a stream: fd = descriptor(Stream);

This is complicated, as we do not know _if_ there will be a native descriptor available, and if operations on that will interfere with the implementation.

availability: right, i was somewhat unprecise. What i meant was the native respresentation of a socket in the given language (a descriptor in C, an IO::Socket obejct in Perl and probably there is something like that in most languages.

I was unprecise as well I guess: you are right, there'll be a native representation in most languages, not doubt. What I mean with availability is best shown in Globus-XIO: I simply do not know _how_ I could obtain the native descriptor from a globus-XIO based implementation: there is no globus-xio call exposing the descriptor.

...

E.g. the implementation might be based on Globus-XIO or on Reliable UDP. For the first I do not know if a descriptor is availbale via the API, for the second there are two descriptors (one tcp, one udp) the application would need to handle.

To handle the second case, 'descriptor' would have to return an array of descriptors. I don't see that in the first case an implementation could return something better than a NULL-array.

It is dependend on the middleware then: the application needs to be aware of the fact that saga implementation returns a single fd, but saga implementation returns 2 fd's, with specific handling requirements. I am not saying that this is impossible. Just would like to be sure that this is the best way to go...

...

Also, the implementation might transparently add a protocol (say checksumming), and direct tempering with the desfriptor might very well break that protocol.

I agree, the only thing the user is allowed to do with the descriptor, is to call 'select'. Read, write, seek, close would most likely break the protocol.

However, this cannot be enforced, and i am aware that this conflicts the principle of hiding the implementation from the user (to minimize the risk that the user breaks something).

I checked with QT, and I think there is a way to handle SAGA events in QT: ------------------------------------------------------------ // this be a callback for a saga stream object, which gets // fired on new data arriving etc. void my_saga_file::saga_cb (void) { emit update_gui (); } my_gui g; my_saga s; QObject::connect (&s, SIGNAL (update_gui (void)), &g, SLOT (saga_cb (void))); ------------------------------------------------------------ (The code above is probably not really correct, but you get the image...) my_saga::saga_cb would need to registerd to saga as callback for events on a stream. Then, if such an event occurs, the callback would trigger (emit) a QT event (update_gui) which would be received by your gui class, and cause, well, the gui to update etc. The QT event mechanism would allow to use any data available in the callback (e.g. string read from the stream) to be signalled to the gui loop as well. So, would that fullfill your requirements? Am am not so sure about AVS and other packages. I did not work with AVS for quite some time, but IIRC, the events have been coupled much tighter to selects on descriptors, with no alternative rounds? However, for all other packages I know (not many), a trivial (e.g. 3 line) translation from saga callbacks to 'native' events seems to exist. Cheers, Andre.

...

So, we might be able to add the API function, but it is difficult to define what it should return in the cases outlined above...

...

However, users have to be aware, that several Streams may share the same decriptor (e.g. in VISIT, if several Streams are tunneled through a single connection of a different protocol like ssh).

...

* a general remark on Streams: i like the idea of keeping the Stream-API close to the BSD socket API. However, as Andrei mentioned, we also often have to deal with more message- or block-oriented communication patterns. In the internal API the we use in the VISIT toolkit, we have therefore added a timeout parameter to all functions and slightly changed the semantics. For example

nread = read(stream, buffer, size, timeout);

works as: try to read size bytes from stream, return if either: - size bytes have been read, or - timeout seconds have passed (wait forever, if timeout < 0), or - an error has occured the function returns the number of bytes read or -1 in case of an error.

This differs from the normal BSD-read, which blocks until *some* data is available and return that data (but nor more than size bytes).

We found that more convenient to implement synchronous message-oriented applications and 'normal' Stream communication with a single and straight-forward API.

Thanks for this feedback! You may have seen the mail exchange to that topic. If you are interested, could you give us your feedback to the proposal written down at:

http://wiki.cct.lsu.edu/saga/space/SAGA+API/Messages

Best regards,

Andre.

...

Best regards, Thomas

Andrei Hutanu wrote:

...

Hi all,

Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API *Resource discovery is not covered by the current API *Job submission to multiple resources (co-scheduling) is not covered by the current API *Simple job submission seems to be covered by the API. Here is a list of things that are not covered (because outside the 80-20 rule?) and there doesn't seem to be a "generic" attribute in the JobDefinition class where these attributes could be specified if the underlying scheduler happens to support them. ** Logical file requirement (the jobs needs to run on a machine where an instance of this particular logical file exists) ** Graphics requirements ** Networking requirements (network interface, bandwidth to ..) ** Performance-based descriptions : GFlops, memory bandwidth ..

Andrei

Thilo Kielmann wrote:

...

Dear all,

the SAGA-RG has its use case document up for public comment, ending oct 30.

So far, there are 0 comments! :-(

I hereby urge everybody to have a look and comment, even if the comment is just trivially in favour...

Thanks for your help,

Thilo

------------------------------------------------------------ Dr. Thomas Eickermann Zentralinstitut fuer Angewandte Mathematik Forschungszentrum Juelich GmbH D-52425 Juelich Phone: +49 2461 61-6596 Email: Th.Eickermann@fz-juelich.de Fax: +49 2461 61-6656

------------------------------------------------------------ Dr. Thomas Eickermann Zentralinstitut fuer Angewandte Mathematik Forschungszentrum Juelich GmbH D-52425 Juelich Phone: +49 2461 61-6596 Email: Th.Eickermann@fz-juelich.de Fax: +49 2461 61-6656

-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

:-D Thanks, Andre. Quoting [Thomas Eickermann] (Dec 13 2005):

Hi Andre,

sorry for responding so slowly, but times are tough as usual in December ...

I finally surrender to your arguments. I was not aware that SAGA will provide callbacks (via the Monitoring interface ?). Using such callbacks, you can probably solve the problem that i have raised in most cases. The rest would fall under the 80/20 rule.

Thanks for the discussion, Thomas

Andre Merzky wrote:

...

Hi Thomas,

Quoting [Thomas Eickermann] (Dec 02 2005):

...

Hi Andre,

thanks for your answer. I agree with your comments that access to raw descriptors is somewhat problematic. Nevertheless i regard them as quite important for implementing real-life interactive applications. Two examples:

1. AVS/Express allows to trigger a module if an event occurs at a descriptor. I do not know of any other way to implement stream communication within AVS/Express and i imagine, that the situation is quite similar for other tools like OpenExplorer.

2. If you use some GUI toolkit (e.g. Qt), you can also register callbacks for events on descriptors. If such a descriptor is not available, the only thing you can probably do is to use timers and polling. There are obviously good reasons to avoid that, if possible.

I agree about the importance.

...

See further comments inline.

Best regards, Thomas

Andre Merzky wrote:

...

Hi Thomas,

sorry for the late answer... *sigh*

Quoting [Thomas Eickermann] (Nov 10 2005):

...

* in both use-cases there is an interactive visualisation/steering application sitting at one end of the stream. Such applications typically use some kind of GUI-toolkit with operates in an event-callback mode or similar, where callbacks can be registered for events occuring at socket/pipe/...-descriptors. On the other hand, in many implementations, a Stream will somehow use a socket, pipe or something else with a descriptor. Therefore we need a function that returns the descriptor associated to a stream: fd = descriptor(Stream);

This is complicated, as we do not know _if_ there will be a native descriptor available, and if operations on that will interfere with the implementation.

availability: right, i was somewhat unprecise. What i meant was the native respresentation of a socket in the given language (a descriptor in C, an IO::Socket obejct in Perl and probably there is something like that in most languages.

I was unprecise as well I guess: you are right, there'll be a native representation in most languages, not doubt.

What I mean with availability is best shown in Globus-XIO: I simply do not know _how_ I could obtain the native descriptor from a globus-XIO based implementation: there is no globus-xio call exposing the descriptor.

...

...

E.g. the implementation might be based on Globus-XIO or on Reliable UDP. For the first I do not know if a descriptor is availbale via the API, for the second there are two descriptors (one tcp, one udp) the application would need to handle.

To handle the second case, 'descriptor' would have to return an array of descriptors. I don't see that in the first case an implementation could return something better than a NULL-array.

It is dependend on the middleware then: the application needs to be aware of the fact that saga implementation returns a single fd, but saga implementation returns 2 fd's, with specific handling requirements.

I am not saying that this is impossible. Just would like to be sure that this is the best way to go...

...

...

Also, the implementation might transparently add a protocol (say checksumming), and direct tempering with the desfriptor might very well break that protocol.

I agree, the only thing the user is allowed to do with the descriptor, is to call 'select'. Read, write, seek, close would most likely break the protocol.

However, this cannot be enforced, and i am aware that this conflicts the principle of hiding the implementation from the user (to minimize the risk that the user breaks something).

I checked with QT, and I think there is a way to handle SAGA events in QT:

------------------------------------------------------------ // this be a callback for a saga stream object, which gets // fired on new data arriving etc. void my_saga_file::saga_cb (void) { emit update_gui (); }

my_gui g; my_saga s;

QObject::connect (&s, SIGNAL (update_gui (void)), &g, SLOT (saga_cb (void))); ------------------------------------------------------------ (The code above is probably not really correct, but you get the image...)

my_saga::saga_cb would need to registerd to saga as callback for events on a stream. Then, if such an event occurs, the callback would trigger (emit) a QT event (update_gui) which would be received by your gui class, and cause, well, the gui to update etc.

The QT event mechanism would allow to use any data available in the callback (e.g. string read from the stream) to be signalled to the gui loop as well.

So, would that fullfill your requirements?

Am am not so sure about AVS and other packages. I did not work with AVS for quite some time, but IIRC, the events have been coupled much tighter to selects on descriptors, with no alternative rounds? However, for all other packages I know (not many), a trivial (e.g. 3 line) translation from saga callbacks to 'native' events seems to exist.

Cheers, Andre.

...

...

So, we might be able to add the API function, but it is difficult to define what it should return in the cases outlined above...

...

However, users have to be aware, that several Streams may share the same decriptor (e.g. in VISIT, if several Streams are tunneled through a single connection of a different protocol like ssh).

...

* a general remark on Streams: i like the idea of keeping the Stream-API close to the BSD socket API. However, as Andrei mentioned, we also often have to deal with more message- or block-oriented communication patterns. In the internal API the we use in the VISIT toolkit, we have therefore added a timeout parameter to all functions and slightly changed the semantics. For example

nread = read(stream, buffer, size, timeout);

works as: try to read size bytes from stream, return if either: - size bytes have been read, or - timeout seconds have passed (wait forever, if timeout < 0), or - an error has occured the function returns the number of bytes read or -1 in case of an error.

This differs from the normal BSD-read, which blocks until *some* data is available and return that data (but nor more than size bytes).

We found that more convenient to implement synchronous message-oriented applications and 'normal' Stream communication with a single and straight-forward API.

Thanks for this feedback! You may have seen the mail exchange to that topic. If you are interested, could you give us your feedback to the proposal written down at:

http://wiki.cct.lsu.edu/saga/space/SAGA+API/Messages

Best regards,

Andre.

...

Best regards, Thomas

Andrei Hutanu wrote:

...

Hi all,

Here is my feedback regarding the Viz-LSU use case. In some cases these requirements might be outside the scope of SAGA, I would like to know if that is the case though ..

*Block-based data transmission is not covered by the current API *Resource discovery is not covered by the current API *Job submission to multiple resources (co-scheduling) is not covered by the current API *Simple job submission seems to be covered by the API. Here is a list of things that are not covered (because outside the 80-20 rule?) and there doesn't seem to be a "generic" attribute in the JobDefinition class where these attributes could be specified if the underlying scheduler happens to support them. ** Logical file requirement (the jobs needs to run on a machine where an instance of this particular logical file exists) ** Graphics requirements ** Networking requirements (network interface, bandwidth to ..) ** Performance-based descriptions : GFlops, memory bandwidth ..

Andrei

Thilo Kielmann wrote:

>Dear all, > >the SAGA-RG has its use case document up for public comment, ending >oct 30. > >So far, there are 0 comments! :-( > >I hereby urge everybody to have a look and comment, even if the >comment is just >trivially in favour... > > >Thanks for your help, > > >Thilo >

------------------------------------------------------------ Dr. Thomas Eickermann Zentralinstitut fuer Angewandte Mathematik Forschungszentrum Juelich GmbH D-52425 Juelich Phone: +49 2461 61-6596 Email: Th.Eickermann@fz-juelich.de Fax: +49 2461 61-6656

-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+