Here is some food for discussion at Wednesdays SAGA session: We have addressed most reported errors and mistakes etc in the core spec by now, apart from 4. These are listed below. Please excuse the length of this mail. I would appreciate if people could read it anyway, so that we don't need to fully describe all items in the SAGA sessions again. 1: - Page 33, figure 2: Picture has no block for URL, URL is nowhere to be found. iovec and parameter are in the wrong block (should not be in io, but in file and rpc) This does not need any discussion, but simply needs to be done. 2: - job::service needs to have its rm URL as attribute, as that URL is needed if more job services are to be created in the same security domain, for example. Otherwise, a job_service created with no URL can never be reconnected to, e.g. to find previously run jobs. A code example would be: { saga::job::service js_1; js.run_job ("/bin/sleep 1000"); } { saga::job::service js_2; std::list <std::string> ids = js_2.list_jobs (); for ( int i = 0; i < ids.size (); i++ ) { saga::job::job j = js_2.get_job (ids[i]); } } In this example, it is not guaranteed that the job from the first code block is amongst the ones found in the second block, as the default js constuctor may very well connect to a different backend. Further, the user has no means to learn about the js URL, to reconnect later on. A fix *could* look like: saga::url u; { saga::job::service js_1; js.run_job ("/bin/sleep 1000"); u = js_1.get_attribute ("url"); } { saga::job::service js_2 (u); std::list <std::string> ids = js_2.list_jobs (); for ( int i = 0; i < ids.size (); i++ ) { saga::job::job j = js_2.get_job (ids[i]); } } Please note that the js URL SHOULD be part of the job id, but that is not a hard requirement to the SAGA implementation. Also, the example above is certainly, well, dumb. But we met a couple of use cases which make it sufficiently painful to keep track of jobs to ask for this to be fixed. 3: - context c'tor should not call set_defaults: that significantly complicates usage if default ctx cannot be initialized. You have probably seen the lengthy email exchange between Ceriel and me on this list. No other opinions have been forthcoming so far, but we need to get this item closed ASAP. So, a short summary: The original behaviour (calling set_defaults in the c'tor) failed for: saga::context c ("globus"); c.set_attribute ("UserProxy", "..."); c.set_defaults (); if no default globus context can be created, a globus context cannot be created at all (set_defaults, and thus the c'tor, would throw). So, we resolved that by not calling set_defaults in the c'tor, which got the above working as it should. Ceriel (and to some extent also Steve) are arguing that set_defaults is not needed in the API at all, but that errors on context initialization should be thrown on the first remote operation where that context is used. I counter-argued that this is an ill defined point, and that I'd rather prefer to have a fixed point in the code where I can expect the SAGA implementation to signal errors in the context initialization. Yes, errors in context usage can still occur later on, but those are well defined. 4: - As suggested earlier, the algorithm to find the most specific error has been changed to ignore the NotImplemented error as long as there were other errors thrown. NotImplemented will be reported only if there are 'only' NotImplemented errors in the error list. That errata item led to a lengthy discussion on several mail threads. Below is a summary of those Issue: ------ The exception precedence list in the spec does not make sense: (a) the NotImplemented exception is actually the least informative one, and should be ate the *end* of the list. (b) for late binding implementation, and for implementations with multiple backends in general, it is very difficult to determine generically which exception is more interesting to the end user. Problem example: ---------------- Assume an implementation of the SAGA file API binds (late) to HTTP and FTP. Assume the following setup: on host a.b.c, an http server (http root = /var/www) and an ftp server (ftp root /var/ftp) are running, using the same credentials for access. The following file exist, and are owned by root (permissions in brackets) URL (rwx) /var/www/etc/ (x--) /var/www/etc/passwd (xxx) /var/www/usw/ (xxx) /var/ftp/etc/ (xxx) /var/ftp/usw/ (x--) /var/ftp/usw/passwd (xxx) Assume a SAGA application wants to open any://a.b.c/etc/passwd for reading. The WWW backend will throw PermissionDenied, the FTP backend with throw DoesNotExist. Both exceptions are correct. There are valid use cases for either exception to be the more specific, and thus, in the spec's argumentation, the more dominant one. Further, upon accessing any://a.b.c/usw/passwd, the situation is excatly inversed. Of course, the implementation will have no means to deduce the intention of the application, and to decide that suddenly the exception from the other backend is more useful. Diagnosis: ---------- The root of the problem is the ability of SAGA to be implemented with late binding. Any binding to a single middleware will result in exactly one error condition, which is to be forwarded to the application. Also, implementations with early bindings can (and indeed will) focus on exceptions which originate from the bound middeware binding for that specific object, and will again be able to report exactly one error condition. (Note that for early binding implementations, the initial operation which causes the implementation to bind to one specific middleware is prone to the same exception ordering problem.) So it is mostly for late binding implementations that this issue arises, when several beckends report errors concurrently, but the standard error reporting mechanism in most languages default to report exactly one error condition. Conclusion: ----------- A global, predefined ordering of exception will be impossible, or at least arbitrary. The native error reporting facilities of most languages will by definition be inadequate to report the full error information of late binding SAGA implementations. That leaves SAGA language bindings with three possibilities: (a) introduce potentially non-native error reporting mechanisms saga::filesystem::file f ("any://a.b.c/etc/passwd"); std::list <saga::exception> el = f.get_exceptions (); // handle all backend exceptions for ( int i = 0; i < el.size (); i++ ) { try { throw el[i]; } catch ( saga::exception::DoesNotExist ) { // handle exception from ftp backend } catch ( saga::exception::PermissionDenied ) { // handle exception from www backend } } (b) acknowledge the described limitation, document it, and stick to the native error reporting mechanism try { saga::filesystem::file f ("any://a.b.c/etc/passwd"); } catch ( saga::exception::DoesNotExist ) { // handle exception from ftp backend } catch ( saga::exception::PermissionDenied ) { // handle exception from www backend (which will not be forwarded in // our example, this this will never be called) } (c) a mixture of (a) and (b), with (b) as default. try { saga::filesystem::file f ("any://a.b.c/etc/passwd"); } catch ( saga::exception::DoesNotExist ) { // handle top level exception } catch ( saga::exception e) { // handle all backend exceptions std::list <saga::exception> el = e.get_all_exceptions (); for ( int i = 0; i < el.size (); i++ ) { try { throw el[i]; } catch ( saga::exception::DoesNotExist ) { // handle exception from ftp backend } catch ( saga::exception::PermissionDenied ) { // handle exception from www backend } } } Note that (c) may not be possible in all languages. Discussion C++ bindings: ------------------------ C++ is actually be able to implement (c). The C++ bindings would then introduce a saga::exception class, and the respective sub classes, which represent the 'most informative/specific' exception. How exactly the 'most informative/specific' exception is selected from multiple concurrent implementations is left to the implementation, and cannot sensibly be prescribed by the specification not the language binding, as discussed above. (The spec could propose such a selection algorithm though). However, the saga::exception class could have the additional ability to expose the full set of backend exceptions, for example as list: std::list <saga::exception> saga::exception::get_all_exceptions (); Further, it would be advisable (for all language bindings actually) to include all error messages from all backend exceptions into the error message of the top level exception (this is already implemented in the CCT's C++ implementation): catch ( saga::exception e ) { std::cerr << e.what (); // print the following message: // exception (top level): DoesNotExist // exception (ftp binding): DoesNotExist - /etc/passwd does not exist // exception (www binding): PermissionDenied - access to /etc denied } Best, Andre. -- Nothing is ever easy.