November 2005 - saga-rg - lists.ogf.org

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

This week's conference call
by Tom Goodale 15 Nov '05

15 Nov '05

Hi, given that there is a face-to-face meeting in Seattle this Thursday, is there any interest at all in holding the scheduled conference call, or shall we postpone it to next week ? Cheers, Tom

2 1

Re: [saga-rg] Meeting at SC05 - Reminder
by Andre Merzky 10 Nov '05

10 Nov '05

Hi again, The final meeting details: 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

Subject: Re: [Fwd: [saga-rg] monitoring, again...]
by Shantenu Jha 09 Nov '05

09 Nov '05

From: <rsirvent(a)ac.upc.edu> To: saga-rg(a)ggf.org Cc: "Rosa M. Badia" <rosab(a)ac.upc.edu> Subject: Re: [Fwd: [saga-rg] monitoring, again...] References: <436F1D90.9020305(a)ac.upc.edu> Hi. I would like to give our opinion (from GRID superscalar's point of view, as a use case of SAGA) about this monitoring API. The way it should be used is almost clear to me (it is very similar to the one defined in GAT). What I find missing is a way of waiting for callbacks to arrive, without having to wait for the task to finish. Of course I'm thinking in a Globus fashion (calls like globus_poll and globus_poll_blocking). I remember something similar in GAT named.. ServiceActions? Its purpose was to give the CPU to the GAT environment in order to do this kind of things (executing the functions to handle de callbacks, for instance). Is there something similar in SAGA? Cheers. Raul. Rosa M. Badia wrote: > Raul, > > em sembla que aixo te a veure amb els callbacks. Li dones una ullada? > > Rosa > > > ------------------------------------------------------------------------ > > Subject: > [saga-rg] monitoring, again... > From: > Andre Merzky <andre(a)merzky.net> > Date: > Sun, 6 Nov 2005 19:48:50 -0600 > To: > Simple API for Grid Applications WG <saga-rg(a)ggf.org> > > To: > Simple API for Grid Applications WG <saga-rg(a)ggf.org> > > >Hi, > >as has been discussed recently, we want to have a simple way >to add callbacks to SAGA. The main use case for this would >be for notification on status changes for tasks and jobs. > >Attached is the re-surrected monitoring package as a >proposal to achieve this. Please note that the package >mentiones steering at various places (mostly commented out) >- that is as of yet not part of the proposal, but should >seen as a possible path for future extension to steering. > >For simplicity, a code example is included. More feedback >to the topic is welcome. I Cc to the GridRPC folx, as they >are probably interested in that. > >Note that the example monitors not the task status, but some >other metric provided by that implementation (bytes written). > >Cheers, Andre. > > > > >+-------------------------------------------------------------+ >Examples: > > monitoring example: monitor a write task > ---------------------------------------- > short version: > -------------- > > class write_metric_cb : public saga::metric::callback > { > public: > void callback (saga::metric & m) > { > std::cout << atoi ( m.get_attribute ("value") ) << " "; > } > }; > > int main (int argc, char** argv) > { > ssize_t len = 0; > std::string str ("Hello SAGA\n"); > std::string url (argv[1]); > > saga::file f (url); > saga::task t = f.task.write (str, &len); > saga::metric m = t.get_metric ("Written"); > > write_metric_cb cb; > m.add_callback (cb); > > t.wait (); > } > > monitoring example: monitor a write task > ---------------------------------------- > long annotated version: > ----------------------- > > // this example shows how monitoring a task can be > // implemented > class write_metric_cb : public saga::metric::callback > { > private: > saga::task t; > > public: > write_metric_cb (const saga::task & _t) { t = _t; } > > void callback (saga::metric & m) > { > int len = atoi ( m.get_attribute ("value") ); > std::cout << "bytes written: " << len << std::endl; > std::cout << "task status: " << t.get_status () << std::endl; > } > }; > > int main (int argc, char** argv) > { > ssize_t len = 0; > std::string str ("Hello SAGA\n"); > std::string url (argv[1]); > > saga::file f (url); > saga::task t = f.task.write (str, &len); > saga::metric m = t.get_metric ("Written"); > > // assume that this m is a discreet metric indicating > // the number of bytes already written. In general, > // the list of metric names has to be searched for an > // interesting metric if name is not known. > > // add the callback > write_metric_cb cb; > m.add_callback (cb); > > // wait until task is done, and give cb chance to get > // called a couple of times > t.wait (); > } >+-------------------------------------------------------------+ > > > >------------------------------------------------------------------------ > > > >+-------------------------------------------------------------+ > > # # > ## ## ### # # # ##### ### #### # # # ### > # # # # # # ## # # # # # # # # ## # # # > # # # # # # # # # # # # # # # # # # # > # # # # # # # # # # # #### # # # # # ### > # # # # # ## # # # # # # # # ## # # > # # ### # # # # ### # # # # # ### > > ## > # # > ## > ### > # # # > # # > ### # > ##### > # # ##### ###### ###### ##### # # # #### > # # # # # # # ## # # # > ##### # ##### ##### # # # # # # # > # # # # ##### # # # # # ### > # # # # # # # # # ## # # > ##### # ###### ###### # # # # # #### > >+-------------------------------------------------------------+ > > >Summary: >======== > > The ability to query Grid entities about state is requested > in several SAGA use cases. Also, the SAGA Task model > incorporates a certain amount of task monitoring. > > This package definition approaches the problem space of > monitoring to unify the various usage patterns (see > details), and to transparently incorporate SAGA task > monitoring. > > A closely related topic is Steering, which is not really seen > independently from Monitoring: in the SAGA approach, a future > Steering may extend Monitoring by the ability to push values > back to the Monitoring source. > >+-------------------------------------------------------------+ > > >Specification: >============== > > package SAGA version 0.1 { > > package Monitoring { > > class Metric implements-all Attribute { > > // need to be derived from for callbacks > class CallBack { > void callback (in Metric metric); > } > > // add a callback, which gets active whenever > // the metric changes > addCallBack (in CallBack cb, > out int cookie); > removeCallBack (in int cb); > > // steering: update the metric value > // update (in string value); > } > > interface Monitorable { > // introspection > getNames (out array<String,1> names); > > // get hook for monitoring/steering > getMetric (in String name, > out Metric metric); > > // set hook for steering > addMetric (out Metric metric); > } > } > } > >+-------------------------------------------------------------+ > >#ifndef SHORT > >Details: >======== > > class Metric > > The fundamenta object introduced in this package is a > Metric. A metric representas an descreet or continuous > observable, which can be read, write, or read/writable. > A readable observable corresponds to classical monitoring, > a writable observable corresponds to steering. > > The approach is severely limited by the use of saga > attributes for the description of a Metric, as these are > only defined in terms of string keys and values. An > extension of the attribute definition by typed and complex > values will greatly improve the usability of this package, > but will also challenge its semantic simplicity. > > The metric MUST provide access to following attributes: > > "Name" : short human readable name > "file.transfer.progress > "Description": extensive human readable description > "This metric gives the status of an > ongoing file transfer as percent > completed." > "Freq": Discreet or Continuous > "CONTINUOUS" > "Mode": "Read", "Write", "ReadWrite" or "Final" > "Read" > "Unit": Unit of values > "percent (%)" > "Type": "String", "Int", "Float" etc. > "Float" > "Value": value of the metric > "20.5" > > The name of the metric must be unique, as the get_metric > call needs to be able to identify the metric to return. > > A writable metric can be updated, and hence provides > remote steering capabilities. However, that is currently > not part of the spec, but noted here as a path for future > extension of the intertface. > > >+-------------------------------------------------------------+ > > >Examples: >========= > > monitoring example: monitor a write task > ---------------------------------------- > > // this example shows how monitoring a task can be > // implemented > class write_metric_cb : public saga::metric::callback > { > private: > saga::task t; > > public: > write_metric_cb (const saga::task & _t) { t = _t; } > > void callback (saga::metric & m) > { > int len = atoi ( m.get_attribute ("value") ); > std::cout << "bytes written: " << len << std::endl; > std::cout << "task status: " << t.get_status () << std::endl; > } > }; > > int main (int argc, char** argv) > { > ssize_t len = 0; > std::string str ("Hello SAGA\n"); > std::string url (argv[1]); > > saga::file f (url); > saga::task t = f.task.write (str, &len); > saga::metric m = t.get_metric ("Progress"); > > // assume that this m is a discreet metric indicating > // the number of bytes already written. In general, > // the list of metric names has to be searched for an > // interesting metric. > > // add the callback > write_metric_callback cb (t); > m.add_callback (cb); > > // wait until task is done, and give cb chance to get > // called a couple of times > t.wait (); > } > > > steering example: steer a remote job > ------------------------------------ > > // this example is concerned with steering (metric is writable). > // However, Steering is currentlu NOT part of the SAGA spec. > class application_observer_cb : public saga::metric::callback > { > private: > saga::task t; > > public: > void callback (saga::metric & m) > { > int val = atoi ( m.get_attribute ("value") ); > std::cout << val << " is the new value." << std::endl; > } > }; > > > int main (int argc, char** argv) > { > saga::job_service js; > > saga::job j = js.run ("remote.host.net", > "my_remote_application"); > > saga::metric m = job.get_metric ("param_1"); > > // assume that m is a discreet metric representing > // a integer parameter for the remote application. > application_observer_cb cb; > m.add_callback (cb); > > for ( int i = 0; i < 10; i++ ) > { > m.update (std::string (i)); > // callback should get called NOW + latency > // if param_1 is read only, update would return an error. > sleep (1); > } > } > > > > steering example: BE a steerable job > ------------------------------------ > > // this example assumes that a job representing THIS application > // (self) allows to add a metric. However, that is currently > // NOT part of the SAGA spec. > class application_observable_cb : public saga::metric::callback > { > private: > int & i; > > public: > application_observable_cb (int & _i) { i = _i; } > void callback (saga::metric & m) > { > int val = atoi ( m.get_attribute ("value") ); > i = val; > std::cout << "new value: " << i << std::endl; > } > }; > > int main (int argc, char** argv) > { > saga::job j = theSession.get_self (); > > saga::metric m ("TestMetric", // name > "This is a test metric", > // description > "Discreet", // frequency > "ReadWrite", // mode > "", // no unit > "Int", // type > "0"); // initial value > > j.add_metric (m); > > // a remote jobs can steer us for 100 seconds > sleep (100); > } > > >+---------------------------------------------------------------+ > >Notes: >====== > > - possible deviation: allow only one CB per metric: > no add/remove, but set/reset CB > >+-------------------------------------------------------------+ > >#endif // SHORT > > >

3 5

Meeting at SC05 - Reminder
by Andre Merzky 09 Nov '05

09 Nov '05

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 states
by 'Andre Merzky' 08 Nov '05

08 Nov '05

Hi Haresh, Thanks for your feedback! Its is nice to see more people reading the posts than the usual suspects :-)) I did not make that clear enough: the schema is only for the task states, not for the job states. If you look at the API spec, the job states are much more detailed. I will try to put them into a diagram soonish as well, and would appreciate your feedback to that. For the task states: tasks in SAGA are just handles to asynchroneous operations really, so fairly simple things. For most implementations, a async call (i.e. task) will probably spawn a thread which performs a operation (e.g. remote file copy), and watch that thread. So a 'failed task' will mean that the file copy failed, not that the thread was killed -- FAILED so always would mean a user handled error. Does that make sense to you? Cheers, Andre. Quoting [Haresh Bhatt] (Nov 07 2005): > > Hi, > > I am not much aware about SAGA activities. However, I could not resist > myself in mentioning few points about the task state management. Please > ignore if it is already discussed. > > 1. Task may encounter two types of errors: (a) User handled error and (b) > system thrown errors. First one is preferred by many programmers to get more > meaningful messages. We need to handle both. > 2. Should we need to handle the states like Suspend, Resume, Restarted, > etc? > 3. How does error will impact on resource management? Will the resource be > freed? If yes then what about the time commitments (reservation)? If No then > what will happen if an error is not handled for long time period? Shall we > still considered the process state as ERRORNEOUS or give another meaningful > state? > 4. If workflow is part of SAGA then we may need to handle few more states. > > Regards, > > Haresh > ---------------------------------------------------------------------------- > -------- > Dr. Haresh S. Bhatt > Scientist/Engineer 'SF' > Indian Space Research Organization > ND/SAG/SITAA > Space Applications Centre > Ahmedabad 380 015 > eMail: haresh(a)sac.isro.gov.in > Phone: > 91-79-2691 4731 (Desk) > 91-79-2691 4744 (Lab 1) > 91-79-2691 4742 (Lab 2) > 91-79-2691 4375 (Lab 3) > 91-79-2691 4376 (Lab 4) > > -----Original Message----- > From: owner-saga-rg(a)ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of > Andre Merzky > Sent: Saturday, November 05, 2005 11:32 AM > To: Simple API for Grid Applications WG > Subject: [saga-rg] task states > > Hi all, > > we had some open notes about task states. Attached is a > proposal for a task state model, which incorporates the task > states we have in the strawman with the proposals. Does > anybody see any difficulties with that? > > Best regards, > > 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

monitoring, again...
by Andre Merzky 07 Nov '05

07 Nov '05

Hi, as has been discussed recently, we want to have a simple way to add callbacks to SAGA. The main use case for this would be for notification on status changes for tasks and jobs. Attached is the re-surrected monitoring package as a proposal to achieve this. Please note that the package mentiones steering at various places (mostly commented out) - that is as of yet not part of the proposal, but should seen as a possible path for future extension to steering. For simplicity, a code example is included. More feedback to the topic is welcome. I Cc to the GridRPC folx, as they are probably interested in that. Note that the example monitors not the task status, but some other metric provided by that implementation (bytes written). Cheers, Andre. +-------------------------------------------------------------+ Examples: monitoring example: monitor a write task ---------------------------------------- short version: -------------- class write_metric_cb : public saga::metric::callback { public: void callback (saga::metric & m) { std::cout << atoi ( m.get_attribute ("value") ) << " "; } }; int main (int argc, char** argv) { ssize_t len = 0; std::string str ("Hello SAGA\n"); std::string url (argv[1]); saga::file f (url); saga::task t = f.task.write (str, &len); saga::metric m = t.get_metric ("Written"); write_metric_cb cb; m.add_callback (cb); t.wait (); } monitoring example: monitor a write task ---------------------------------------- long annotated version: ----------------------- // this example shows how monitoring a task can be // implemented class write_metric_cb : public saga::metric::callback { private: saga::task t; public: write_metric_cb (const saga::task & _t) { t = _t; } void callback (saga::metric & m) { int len = atoi ( m.get_attribute ("value") ); std::cout << "bytes written: " << len << std::endl; std::cout << "task status: " << t.get_status () << std::endl; } }; int main (int argc, char** argv) { ssize_t len = 0; std::string str ("Hello SAGA\n"); std::string url (argv[1]); saga::file f (url); saga::task t = f.task.write (str, &len); saga::metric m = t.get_metric ("Written"); // assume that this m is a discreet metric indicating // the number of bytes already written. In general, // the list of metric names has to be searched for an // interesting metric if name is not known. // add the callback write_metric_cb cb; m.add_callback (cb); // wait until task is done, and give cb chance to get // called a couple of times t.wait (); } +-------------------------------------------------------------+ -- +-----------------------------------------------------------------+ | 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 (cdekate@cct.lsu.edu): SAGA API comments
by Andre Merzky 06 Nov '05

06 Nov '05

Hi, below are Chirags comments to the saga strawman and his use case. I think the suggession to add an update_location method to logical files is a good one. It basically would be an atomic version of a remove_location add_location pair. Thanks Chirag! Cheers, Andre. ----- Forwarded message from Chirag Dekate <cdekate(a)cct.lsu.edu> ----- > Date: Fri, 28 Oct 2005 11:00:14 -0500 > From: Chirag Dekate <cdekate(a)cct.lsu.edu> > To: Hartmut Kaiser <Hartmut.Kaiser(a)gmail.com>, > Andre Merzky <andre(a)merzky.net> > Subject: SAGA API comments > Cc: Gabrielle Allen <gallen(a)cct.lsu.edu> > > In the Logical Files section, > > Consider a scenario where one logical file name (LFN) maps to > different physical file names (PFN). The API description in its > current form allows end user to create such LFN-PFN mappings. > However in cases where the LFN - PFN mappings needs to be updated > based on the current state / availability of the Physical Files, the > existing API will need to be extended. > > General comments regarding the Strawman API Document: > The Context API : To be able to seamlessly switch between different > authentication and authorization mechanisms would enable several > scenarios that would enable use of datasets and resources in practical > situations where environments are based on heterogeneous middleware > technologies. > > As an overall comment, once the strawman is finalized it would be > helpful if samples with ample documentation are made available. There > are several API constructs whose use would become clearer if sample > application strategies are presented. One way would be an idea bank > that acts as a repository for ideas on how the API would be used to > solve different usecases, moderated by SAGA steering committee. > > Chirag Dekate ----- 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 1

Conference calls
by Tom Goodale 06 Nov '05

06 Nov '05

Hi, I've yet to see a reply to the below. Do we want the next call on the 17th as currently scheduled, or on the 10th and then biweekly from then ? Or should we stop having regular conference calls alltogether ? Cheers, Tom ---------- Forwarded message ---------- Date: Fri, 4 Nov 2005 11:23:15 +0000 (GMT) From: Tom Goodale <goodale(a)cct.lsu.edu> To: saga-rg(a)ggf.org Cc: Tom Goodale <goodale(a)cct.lsu.edu> Subject: Re: [saga-rg] Details for call 03/11/05 (fwd) I'd like to keep the calls at the advertised times if at all possible, so worst case move it to next Thursday, which would have the advantage of not clashing with supercomputing. Can I have some sort of show of hands as to having the next one on the tenth or the 17th ? I've currently booked a conference slot for the 17th, but can easily get rid of that and move us onto a 10th, 24th, 1st, 8th, 15th, 22nd schedule if that would be better for people. Cheers, Tom On Thu, 3 Nov 2005, Andre Merzky wrote: > My apologies, > > I have not seen yesterdays mail, and completely forgot about > the call... :-( > > I would like to start iterating the issue list again, and to > at least spread some TODO assignments over it. Could we > have a call the same time omorrow perhaps? > > Cheers, Andre. > > > Quoting [Tom Goodale] (Nov 03 2005): >> Date: Thu, 3 Nov 2005 16:08:36 +0000 (GMT) >> From: Tom Goodale <goodale(a)cct.lsu.edu> >> To: saga-rg(a)ggf.org >> Subject: [saga-rg] Details for call 03/11/05 (fwd) >> >> >> Hi, >> >> there doesn't seem to be anyone else joining; I will give it another >> couple of minutes... >> >> Cheers, >> >> Tom >> >> ---------- Forwarded message ---------- >> Date: Wed, 2 Nov 2005 10:54:12 +0000 (GMT) >> From: Tom Goodale <goodale(a)cct.lsu.edu> >> To: saga-rg(a)ggf.org >> Subject: [saga-rg] Details for call 03/11/05 >> >> >> Hi, >> >> Tomorrow's details are below. >> >> NOTE: this week the regular number was again completely booked, so we have >> a new number; I will try to book earlier next time so hopefully we should >> be back to the regular number soon... >> >> Date: Thu 3 November 2005 >> Time: 1700 Central European Summer Time >> 1600 Greenwich Mean Time >> 1000 Central Standard Time >> 0800 Pacific Standard Time >> Number: +1-620-782-2200 >> >> Code: 808044 >> >> Tentative Agenda: >> >> 1. Agenda bashing >> 2. Note Taker >> 3. New charter >> 4. Requirements document >> 5. Issue list >> >> I will send a final agenda tomorrow, so if there are more things to >> discuss, or you want to remove any of the above, let me know. >> >> Cheers, >> >> Tom > > > >

2 1

C++ binding: question
by Andre Merzky 05 Nov '05

05 Nov '05

Hi all, here is another question about the C++ language binding we stukmbled upon. The API spec says that the session is an optional argument to each object creation in SAGA. If the session is not given, a default session (theSession) is to be associated with the object. Now, consider a object which has a number of optyional parameters already (example not spec conform): saga::file (string url, mode=saga::file::mode::RO, saga::session s); If a programmer wants to specify a session, he NEEDS to specify mode, and all other optional parameters of the constructor. For a programmer who always specifies a session that is awkward. OTOH, a constructor like saga::file (saga::session s, string url, mode=saga::file::mode::RO); would giove that programmer the ability to use session and rely on parameters defaults, but for another programmer who does not use an explicit session it would require to ALWAYS specify the session anyway: saga::file f (theSession, url); The solution we would like to propose is to introduce two versions of all constructors: saga::file ( string url, mode=saga::file::mode::RO); saga::file (saga::session s, string url, mode=saga::file::mode::RO); which would accomodate both use cases nicely. To be sure: that affects only the C++ language bindings - that might look totally different for other languages. Any comments? If not, we go for the proposed solution... Cheers, 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 | | +-----------------------------------------------------------------+

4 5