Quoting [Mathijs den Burger] (Apr 08 2009):
Hi all,
What is the 'right' behavior of a SAGA implementation when a user adds multiple contexts of the same type to a session?
Example: in an file browsing application on top of SAGA, a user creates two contexts of type "ftp": one with username "anonymous" and an empty password (for anonymous FTP access), and one with username "john" and password "1234" (to access a private FTP server).
Should a SAGA implementation try all contexts of type "ftp" in this case, or just one of them?
All of them.
And what if both contexts actually work for a certain URL, but result in different access rights?
This can't be resolved sensibly. So, its up to the implementation.
In that case, a directory.cwd() call may succeed with one context but fail with another one due to insuffient permissions. Should an implementation then also retry the other available contexts in the cwd() method, or fail with an AuthorizationFailed exception?
In a late-binding implementation, one would expect the adaptor to try the other adaptor on a second call, if that fails. More, the implementation may try another adaptor altogether (e.g. gridftp, which can also talk ftp). Yes, that may lead to name space inconsitencies. That cannot be helped. The only way to avoid that is to use one set of adaptors, and on set of contexts.
Currently, the SAGA spec leaves the 'right' behavior entirely up to the application.
Because this is in fact implementation specific. An early-binding implementation may not be able to try more than one adaptor, and/or context. A late-binding implementation may be able to do so. The SAGA spec says though: p.81: "Multiple contexts can co-exist in one session â it is up to the implementation to choose the correct context for a speciï¬c method call." Please check also p.18 "2.4.1 Early versus late binding", which addresses some of your points.
Should a multi-adaptor SAGA implementation leave the behavior to the adaptors? In that case, different adaptors may do different things. One adaptor may try all contexts with the right type, while another one may only try just one. Some adaptors may only try multiple contexts in the constructor, while others may also do this in the individual methods. Is each implementation supposed to prescribe 'the right way' to adaptor writers? Should each adaptor document its use of contexts?
Yes: all these points are implementation specific, and should be documened by the implementation/adaptors.
Should each adaptor mimic the behavior of the underlying middleware? (e.g. an SSH adaptor tries multiple keys automatically, but an FTP adaptor only tries one username/password combination). Or would it be desirable if the spec prescribes something here?
MW specific semantics should not be exposed, if possible. Instead, I'd suggest that adaptors for one specific implementation should behave consistently, no matter what MW is used. Note to self: that semantics (what context are chosen, when the are chosen early/late bindings, adaptor versus method level binding, ...) should be part of an SPI specification, which some people on this list are known to ponder about. Hey Steve ;-) Cheers, Andre.
best, -Mathijs
-- Nothing is ever easy.